idnits 2.17.1 draft-georgescu-opsec-ipv6-trans-tech-threat-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 30, 2016) is 2857 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 834, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Georgescu, Ed. 3 Internet-Draft NAIST 4 Intended status: Informational June 30, 2016 5 Expires: January 1, 2017 7 The STRIDE towards IPv6: A Threat Model for IPv6 Transition Technologies 8 draft-georgescu-opsec-ipv6-trans-tech-threat-model-01 10 Abstract 12 This document provides a structured approach for analyzing the 13 threats associated with the various IPv6 transition technologies 14 specified by the IETF. The threat model is built around the 15 established STRIDE threat classification and is aimed at existing 16 IPv6 transition technologies, as well as their future developments. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 1, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. The Generic Categories of IPv6 Transition Technologies . . . 3 55 4. Building The Threat Model . . . . . . . . . . . . . . . . . . 4 56 4.1. Establish the function . . . . . . . . . . . . . . . . . 4 57 4.2. Identify the generic category . . . . . . . . . . . . . . 4 58 4.3. Decompose the technology . . . . . . . . . . . . . . . . 4 59 4.4. Identify the threats . . . . . . . . . . . . . . . . . . 5 60 4.4.1. STRIDE-DFD Assoctiation . . . . . . . . . . . . . . . 5 61 4.4.2. Level of Trust . . . . . . . . . . . . . . . . . . . 6 62 4.4.3. Documenting the Threats . . . . . . . . . . . . . . . 6 63 4.4.4. Complex Threats . . . . . . . . . . . . . . . . . . . 7 64 4.5. Review, Repeat and Validate . . . . . . . . . . . . . . . 7 65 5. Dual Stack Threat Model . . . . . . . . . . . . . . . . . . . 8 66 5.1. Establish the Function . . . . . . . . . . . . . . . . . 8 67 5.2. Identify the Generic Category . . . . . . . . . . . . . . 8 68 5.3. Decompose the Technology . . . . . . . . . . . . . . . . 8 69 5.4. Identify the threats . . . . . . . . . . . . . . . . . . 9 70 5.4.1. STRIDE-DFD Assoctiation . . . . . . . . . . . . . . . 9 71 5.4.2. From Trust to Likelihood . . . . . . . . . . . . . . 10 72 5.4.3. Documenting the Threats . . . . . . . . . . . . . . . 10 73 5.4.4. Complex Threats . . . . . . . . . . . . . . . . . . . 11 74 5.5. Review, Repeat and Validate . . . . . . . . . . . . . . . 12 75 6. Single Translation Threat Model . . . . . . . . . . . . . . . 13 76 6.1. Decompose the Technology . . . . . . . . . . . . . . . . 13 77 6.2. Identify the threats . . . . . . . . . . . . . . . . . . 14 78 7. Double Translation Threat Model . . . . . . . . . . . . . . . 15 79 7.1. Decompose the Technology . . . . . . . . . . . . . . . . 15 80 7.2. Identify the threats . . . . . . . . . . . . . . . . . . 15 81 8. Encapsulation Threat Model . . . . . . . . . . . . . . . . . 16 82 8.1. Decompose the Technology . . . . . . . . . . . . . . . . 16 83 8.2. Identify the threats . . . . . . . . . . . . . . . . . . 17 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 12.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 21 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 When building an IPv6 transition plan, security is arguably one of 96 the biggest concerns for network operators, as a heterogeneous IPv4 97 and IPv6 environment greatly increases the attack surface. To that 98 end, building a threat model for IPv6 transition technologies can 99 help clarify and categorize the associated security threats. In 100 turn, this should facilitate the search for mitigation solutions. 102 The security considerations of IPv6 transition technologies has 103 generally been analyzed in each of the corresponding specifications, 104 and some documents have discussed the general threats associated with 105 transition technologies (see e.g. [RFC4942]). 107 However, more structured threat modeling has proved useful for 108 understanding the security of intricate systems. Structured 109 approaches allows one to discover, categorize and classify the 110 threats according to their potential impact on the system. 111 Considering the complicated nature of IPv6 transition technologies, 112 threat modeling makes a good candidate for better understanding their 113 security implications. This document follows a structured approach 114 for analyzing the threats asociated with transition technologies, 115 that considers the functions of a transition technology as well as 116 the cntext in which the technology is used. 118 The threat model uses the established STRIDE mnemonic and threat 119 classification. STRIDE stands for Spoofing, Tampering, Repudiation, 120 Information Disclosure, Denial of service and Elevation of Privilege, 121 a generic list of threats which can be used to classify various 122 threats and provides some basic mitigation directions. Since similar 123 transition technologies can be associated with a similar list of 124 threats, the document considers the generic classification of IPv6 125 transition technologies described in [draft-bmwg-v6trans]. 127 2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 3. The Generic Categories of IPv6 Transition Technologies 135 Table 1 presents the generic categories described in 136 [draft-bmwg-v6trans] and some sample IPv6 transition technologies 137 specified by the IETF. 139 Table 1. IPv6 Transition Technologies Categories 140 +---+--------------------+------------------------------------+ 141 | | Generic category | IPv6 Transition Technology | 142 +---+--------------------+------------------------------------+ 143 | 1 | Dual-stack | Dual IP Layer Operations [RFC4213] | 144 +---+--------------------+------------------------------------+ 145 | 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] | 146 +---+--------------------+------------------------------------+ 147 | 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] | 148 +---+--------------------+------------------------------------+ 149 | 4 | Encapsulation | DSLite [RFC6333], MAP-E [RFC7597] | 150 | | | Lightweight 4over6 [RFC7596] | 151 | | | 6RD [RFC5569] | 152 +---+--------------------+------------------------------------+ 154 4. Building The Threat Model 156 To build a threat model for IPv6 transition technologies a series of 157 steps is recommended. The steps were inspired by the threat 158 modelling approach described in [stride-shostack]. These steps are 159 detailed in the following subsections. 161 4.1. Establish the function 163 The function of the IPv6 transition technology needs to be clearly 164 documented. Depending on the context, the technology can incorporate 165 multiple services, which need to be clearly identified in order to 166 perform an effective threat analysis. 168 4.2. Identify the generic category 170 The category should be identified considering the generic 171 classification defined in Section 3. This step can help reuse the 172 threat analysis data for technologies which are part of the same 173 category. 175 4.3. Decompose the technology 177 Build a data flow diagram (DFD) and highlight the entry points, 178 protected resources and trust boundaries. The entry points should be 179 assigned a level of trust considering the trust boundaries. 181 The external entities, process, data store and data flow elements 182 should be depicted in the same diagram. The IP protocol suite and 183 the protocols used for the designated function should be identified 184 as well. This can narrow down the attack surface. 186 Figure 1 presents the basic elements of a data flow diagram as well 187 as general rules for their association with network elements. 189 +----------+ 190 | External | Represents a network node which is outside 191 | Entity | the control of a network provider 192 +----------+ 193 ___ 194 ,' `. Represents a middle-box or a network node 195 | Pro | which processes translated or encapsulated 196 \ cess/ traffic 197 `---' 199 ============ 200 Data store Represents a node where user and provider 201 ============ data is stored 203 Data Flow 204 ------------> Data in transit exchanged between network elements 206 Trust 207 () The border which marks the part of the 208 () network considered outside the control 209 () of a network provider 210 boundary 212 Figure 1. DFD Elements 214 4.4. Identify the threats 216 4.4.1. STRIDE-DFD Assoctiation 218 The STRIDE model associates the six categories of threats to each of 219 the elements described in the DFD. Based on this association, we get 220 an initial assessment of the threats as shown in Table 2. To 221 clarify, a data flow, for example, is susceptible to tampering, 222 information disclosure and denial of service threats. The initial 223 threat assessment must be followed by a detailed analysis which 224 should consider the protocols used in conjuncture with the transition 225 technology. 227 Table2. DFD-STRIDE Associations 229 +----+---+---+---+---+---+ 230 | S | T | R | I | D | E | 231 +----+---+---+---+---+---+ 232 | # | | # | | | | 233 +----+---+---+---+---+---+ 234 | O | O | O | O | O | O | 235 +----+---+---+---+---+---+ 236 | | = | = | = | = | | 237 +----+---+---+---+---+---+ 238 | | > | | > | > | | 239 +----+---+---+---+---+---+ 240 | # | External entity | 241 +----+-------------------+ 242 | O | Process | 243 +----+-------------------+ 244 | = | Data store | 245 +----+-------------------+ 246 | > | Data flow | 247 +----+-------------------+ 249 4.4.2. Level of Trust 251 We associate a level of trust with each entry point. Entry points 252 that are trusted are assumed to behave as expected. That is, if the 253 entry point is considered trusted, we can assume the likelihood of an 254 attack is low. Furthermore, the six categories of STRIDE attacks 255 could be assigned a likelihood by considering their association with 256 the DFD elements that are entry points. 258 For instance, let's suppose we have an untrusted entry point (High 259 likelihood of exploitation) which is also an external entity. 260 Spoofing and repudiation are potential threats for an external 261 entity. By association, the two types of attacks can be considered 262 to have a high likelihood of being exploited. Using this logic, we 263 can assign a likelihood value to each found threat. This can 264 represent a base for prioritizing mitigation solutions. The 265 likelihood levels can be defined in accordance with the levels of 266 trust assigned to the the entry points. 268 4.4.3. Documenting the Threats 270 Each discovered threat should be documented using the format 271 presented in Table 3. 273 Table2. Threat Info Format 275 +-------------+-----------------------------------------------+ 276 | Field Name | Description | 277 +-------------+-----------------------------------------------+ 278 | Threat-ID | A code associated with each identified threat | 279 +-------------+-----------------------------------------------+ 280 | Description | A summarized description of the threat | 281 +-------------+-----------------------------------------------+ 282 | STRIDE | The association with the STRIDE categories | 283 +-------------+-----------------------------------------------+ 284 | Mitigation | Details about possible mitigation solutions | 285 +-------------+-----------------------------------------------+ 286 | Likelihood | Likelihood of the threat being exploited | 287 +-------------+-----------------------------------------------+ 288 | Validation | Empirical validation data | 289 +-------------+-----------------------------------------------+ 291 The Threat-ID is supposed to be an easy way to refer and identify the 292 threat within the IETF. The tentative format is IETF-TDB-[associated 293 protocol/technology]-[serial number]. IETF-TDB stands for IETF 294 Threat Database in the hope that in the future a threat database will 295 be maintained within the IETF. The serial number is incremented with 296 each threat found for a particular protocol or technology. 298 4.4.4. Complex Threats 300 As the subcomponents and subprotocols interact, the threats can fuse 301 and result in convoluted threats with a higher likelihood of 302 exploitation. Depending on the list of discovered threats, the 303 possibility of a fusion between threats should be analyzed. 305 4.5. Review, Repeat and Validate 307 Steps 1 and 3 have to be reviewed in the context of potential changes 308 in the technology function and associated protocols. Step 4 should 309 be repeated periodically, as threats may have been overlooked, or the 310 context set by steps 1 and 3 may have changed. If the transition 311 technologies have existing implementations, the analysis should be 312 confirmed with empirical data. 314 The next sections applied the proposed threat modeling approach to 315 the IPv6 transition technologies identified in Section 3. 317 5. Dual Stack Threat Model 319 5.1. Establish the Function 321 The function for dual-stack transition technologies is to ensure a 322 safe data exchange over a dual-stack infrastructure. In other words, 323 the data can be transfered over both IPv4 and IPv6. From a network 324 service perspective, the main function is data forwarding. This 325 includes interior gateway routing solutions. We start with the 326 assumption that services such as address provision, DNS resolution or 327 exterior gateway routing are performed by other nodes within the core 328 network. This assumption in common for all the four generic 329 categories of IPv6 transition technologies. 331 5.2. Identify the Generic Category 333 Since we are targeting the generic category itself, the step is 334 unnecessary here. This stands for the other three categories as 335 well. 337 5.3. Decompose the Technology 339 A DFD for dual-stack transition technologies is presented in 340 Figure 2. The diagram represents a basic use case and includes a 341 minimal set of elements. 343 Domain A-DS Core ___ Domain Domain B-DS 344 +----------+ ( ,' `. ) ============ 345 | Customer |-----(------->| DS |------- )---> Provider 346 | Device |<----(-------- \ node/<--------)---- Data Store 347 +----------+ ( `---' IPv4/IPv6) ============ 348 E P E P E P 349 _____________________________________________________________________ 350 Legend ___ Trust 351 +----------+ ,' `. ============ Data Flow () E=Entry 352 | External | | Pro | Data store ------------> () point 353 | Entity | \ cess/ ============ () P=Protected 354 +----------+ `---' boundary 356 Figure 2. Data Flow Diagram (DFD) for Dual Stack (DS) technologies 358 In Domain A, which is assumed to be on the customer side we have a 359 Customer Device which initiates the data exchange. It represents one 360 of the entry points of the system and contains important data, which 361 should be regarded as an asset and protected. The Customer Device is 362 regarded as an external element because it is outside the control 363 zone of the assumed network provider. The data request is 364 transmitted over IPv4 or IPv6 to a Dual-stack node. 366 The Dual-stack node is another entry point and contains valuable 367 topology information which should to protected as well. The Dual- 368 stack node forwards in turn the data request to the provider data 369 store. The Data store is the last entry point in the system and it 370 is assumed to contain valuable data. The data reply is forwarded 371 back to the customer device. 373 The only trusted entry point in the system is the Dual-stack node. 374 The other two entry points are considered untrusted, since they are 375 outside the control of the production network.That means they can be 376 exploited with a higher likelihood by an attacker. 378 Considering the data can be transferred over both IPv4 and IPv6, we 379 need to consider both IP protocol suites. Furthermore, the 380 possibility of using security and routing protocols should be 381 considered. 383 5.4. Identify the threats 385 5.4.1. STRIDE-DFD Assoctiation 387 By analyzing the DFD in association with the STRIDE threats per 388 element chart, we can make the associations depicted in Table 3. 390 Table3. DFD-STRIDE Associations DS 392 +----+---+---+---+---+---+ 393 | S | T | R | I | D | E | 394 +----+---+---+---+---+---+ 395 |#-H | |#-H| | | | 396 +----+---+---+---+---+---+ 397 | O-L|O-L|O-L|O-L|O-L|O-L| 398 +----+---+---+---+---+---+ 399 | |=-H|=-H|=-H|=-H| | 400 +----+---+---+---+---+---+ 401 | |>-H| |>-H|>-H| | 402 +----+---+---+---+---+---+ 403 | # | Customer device | 404 +----+-------------------+ 405 | O | DS node | 406 +----+-------------------+ 407 | = |Provider data store| 408 +----+-------------------+ 409 | > | Data flow | 410 +----+-------------------+ 412 5.4.2. From Trust to Likelihood 414 Looking at the associations in Table 3, The Customer Device can be 415 subject to spoofing and repudiation attacks. It being an untrusted 416 entry point, that means there is a high likelihood of an attack. 417 This is marked in Table 3 with H. 419 The Dual-stack node can be subject to all six types of attacks. 420 However, the likelihood of that happening is low, considering it is a 421 trusted entry point. 423 The Data flow is vulnerable to tampering, information disclosure and 424 denial of service. Considering it traverses untrusted parts of the 425 system, the level of likelihood of an attack on the data flow is 426 high. 428 Lastly, the Data store could potentially be targeted by tampering, 429 repudiation, information disclosure and denial of service attacks. 430 The likelihood for these to happen is high as well, the data store 431 being an untrusted entry point. 433 5.4.3. Documenting the Threats 435 The Tables 5-10 of the Appendix contain a non-exhaustive collection 436 of existing threats, which have been collected by surveying a part of 437 existing literature on this subject. For further documentation, each 438 threat has been provided with a reference in the first column. For 439 reuse purposes, the threats are organized according to the categories 440 of protocols which would be necessary for accomplishing the function 441 of the IPv6 transition technologies. 443 For dual-stack transition technologies the protocol threats 444 associated with the IPv4 suite (Table 6), IPv6 suite(Table 7), 445 routing (Table 10) and switching (Table 5) could potentially be 446 exploited from the 3 entries of the system: the untrusted (High 447 likelihood of exploitation) Customer device, the trusted (Low 448 likelihood of exploitation) Dual-stack node (Process) and untrusted 449 (High likelihood of exploitation) Provider Data store. 451 The IPv4 suite, transport layer and most of the IPv6 suite protocols 452 are associated with all the elements of the DFD. By extrapolation, 453 their threats have a high likelihood of occurrence. Some of the IPv6 454 protocol threats (Table 7), namely IETF-TDB-ND-3 to IETF-TDB-ND-6 and 455 the Layer 2 technologies' threats (Table 5) can only be associated 456 with routers or switches. In the context of the DFD, they could only 457 be associated with the Dual-stack node. That means they have a low 458 likelihood of occurrence. Similarly, the routing protocols 459 (Table 10) can only be associated with the Dual-stack node. By 460 association, they also have a low likelihood of being exploited. 462 5.4.4. Complex Threats 464 By analyzing the interaction between the three elements of the DFD 465 and the protocols used by Dual stack transition technologies, we can 466 uncover other threats. For example, if the IETF-TDB-ARP-1(ARP cache 467 poisoning) is used to perform a Denial of Service attack on the Dual- 468 stack node from the Customer device, the likelihood of exploitation 469 rises for the IETF-TDB-ND-10 (ND Replay Attacks) threats. IETF-TDB- 470 ARP-1 could be replaced by any other DoS threat associated with the 471 IPv4 protocol suite. This complex threat could be prevented by 472 ensuring that the IPv4 suite DoS threats are properly mitigated. 473 Examples of convoluted threats for the four generic IPv6 transition 474 technologies are presented in Table 4. 476 Table4. Complex Threats 478 +---+------------+-------------+---+---+---+---+---+---+------------+ 479 | | ThreatID | Description | S | T | R | I | D | E | Mitigation | 480 +---+------------+-------------+---+---+---+---+---+---+------------+ 481 | 1 | IETF-TDB | IETF-TDB | H | H | H | H | H | | | 482 | V | -DS-1 | -ARP-1 | | | | | | | DoS | 483 | | | + | | | | | | | Mitigation | 484 | | | IETF-TDB | | | | | | | for | 485 | | | -ND-4 | | | | | | | IPv4 suite | 486 +---+------------+-------------+---+---+---+---+---+---+------------+ 487 | 2 | IETF-TDB | IETF-TDB | H | H | H | H | H | H | Crypto | 488 | V | -DS-2 | -ARP-1 | | | | | | | authen | 489 | | | + | | | | | | | | 490 | | | IETF-TDB | | | | | | | | 491 | | | -OSPFv3-1 | | | | | | | | 492 +---+------------+-------------+---+---+---+---+---+---+------------+ 493 | 3 | | IETF-TDB | H | | H | H | H | | No widely | 494 | X | IETF-TDB | IP/ICMP-3 | | | | | | | accepted | 495 | | -1transl-1 | + | | | | | | | mitigation | 496 | | | IETF-TDB | | | | | | | | 497 | | | -ICMPv6-1 | | | | | | | | 498 +---+------------+-------------+---+---+---+---+---+---+------------+ 499 | 4 | IETF-TDB | IETF-TDB | H | H | H | H | H | | Block | 500 | V | -1transl-2 | -TCP-1 | | | | | | | non- | 501 | | | + | | | | | | | internal | 502 | | | IETF-TDB | | | | | | | traffic | 503 | | | -ND-4 | | | | | | | | 504 +---+------------+-------------+---+---+---+---+---+---+------------+ 505 | 5 | | IETF-TDB | L | L | L | L | L | | No widely | 506 | X | IETF-TDB | -IP/ICMP-4 | | | | | | | accepted | 507 | | -2transl-1 | + | | | | | | | mitigation | 508 | | | IETF-TDB | | | | | | | | 509 | | | -ND-4 | | | | | | | | 510 +---+------------+-------------+---+---+---+---+---+---+------------+ 511 | 6 | IETF-TDB | IETF-TDB | L | L | L | L | L | L | reverse | 512 | V | -2transl_2 | -IP/ICMP-1 | | | | | | | path | 513 | | | + | | | | | | | checks | 514 | | | IETF-TDB | | | | | | | | 515 | | | -OSPFv3-1 | | | | | | | | 516 +---+------------+-------------+---+---+---+---+---+---+------------+ 517 | 7 | | IETF-TDB | | | | H | H | | IPv4 | 518 | | IETF-TDB | -IPv6-1 | | | | | | | firewall | 519 | | -encaps-1 | + | | | | | | | before | 520 | | | IETF-TDB | | | | | | | decaps | 521 | | | -4encaps_1 | | | | | | | | 522 +---+------------+-------------+---+---+---+---+---+---+------------+ 523 | Legend | | 524 +---------------+---------------------------------------------------+ 525 | H | associaced with | | L | associaced with | 526 | | High likelihood | | | Low likelihood | 527 +---+----------------------------+-------+---+----------------------+ 529 Another convoluted threat can result from exploiting IPv4 or IPv6 530 spoofing threats to increase the likelihood of an attack on routing 531 protocols with simple authentication, such as or IETF-TDB-OSPFv3-1, 532 IETF-TDB-OSPFv2-1 or IETF-TDB-RIPv2-1. Since the attack could be 533 performed from an untrusted entry point (Customer device or Data 534 store), the likelihood of the threat being exploited rises to High. 535 This type of attack can be mitigated by using cryptographic 536 authentication for the routing protocols. 538 The list of threats can help technology implementors and network 539 operators alike prioritize the threats and mitigate accordingly. 541 5.5. Review, Repeat and Validate 543 This step is necessary if the technology analyzed or associated 544 protocols change. For example if the routing system were to be only 545 OSPFv3, then the threats associated with other routing protocols 546 could be ignored. Also, the detailed analysis of threats is far from 547 exhaustive. In terms of convoluted new threats, only a few are 548 presented as an example. If this was to be an updated database of 549 threats, it would need constant update. 551 To further validate the presented threats, a simple penetration 552 testbed was built. The details of the testbed are presented in 553 Figure 3. MAP-T [RFC7599] was used as transition technology. Asamap 554 [asamap2014], a transition implementation developed in Japan, was 555 used as the base for MAP-T. The threats which were successfully 556 emulated, have been marked accordingly in the first column of 557 Table 4. In the case of the convoluted threats identified for Dual- 558 stack transition technologies, both threats were emulated 559 successfully by performing ARP Cache Spoofing, Neighbor Advertisement 560 (NA) flooding and simple traffic analysis. 562 +----------+ 563 +---------+---------------+ Kali | 564 |---------|+--------------> Attacker | 565 || || +---+^-----+ 566 || || || 567 || || ___ || __ 568 +--v-------+ || ( ,' `. || ,' `. ) =========== 569 | Win8 +-+|--(---->+ amap +-+|->+ amap +-----)-----> Ubuntu 570 | Host <--+--(-----+\ CE /<--+--+\ BR /<-----)-----+ Server 571 +----------+ ( `+-+' IPvY `+-+' IPvX ) =========== 572 E P E P E P E P 574 Figure 3. Pentestbed Setup 576 6. Single Translation Threat Model 578 To avoid redundant information, the following three subsections will 579 only mark the differences with the threat modeling process presented 580 for Dual-stack transition technologies. 582 One of the fundamental differences is that the single translation 583 technologies would require a node to algorithmically translate the 584 IPvX packets to IPvY, as shown in Figure 4. 586 6.1. Decompose the Technology 588 A DFD for single translation transition technologies is presented in 589 Figure 4. The diagram represents a basic use case and includes a 590 minimal set of elements. 592 Domain A-IPvX Core___ Domain Domain B-IPvY 593 +----------+ IPvX ( ,' `. IPvY ) ============ 594 | Customer |------(------>| Tra |------- )---> Provider 595 | Device |<-----(------- \ nsl /<--------)---- Data Store 596 +----------+ IPvX ( `---' IPvY ) ============ 597 E P E P E P 598 _____________________________________________________________________ 599 Legend ___ Trust 600 +----------+ ,' `. ============ Data Flow () E=Entry 601 | External | | Pro | Data store ------------> () point 602 | Entity | \ cess/ ============ () P=Protected 603 +----------+ `---' boundary 605 Figure 4. DFD for 1transl technologies 607 6.2. Identify the threats 609 For both translation directions 4->6 and 6->4, the threats for the 610 IPv4 suite (Table 6), IPv6 suite (Table 7), routing (Table 10) and 611 switching (Table 5) should be considered. There are technologies 612 that use stateful mapping algorithms e.g. Stateful NAT64 [RFC6146], 613 which create dynamic correlations between IP addresses or {IP 614 address, transport protocol, transport port number} tuples. 615 Consequently, we need to consider the protocols used at the transport 616 layer (Table 9) as part of the attack surface. The threats presented 617 in Table X, associated with the IP/ICMP translation algorithm (IP/ 618 ICMP) should be considered as well. 620 In terms of convoluted threats, one example could be exploiting the 621 IETF-TDB-IP/ICMP-3 threat (IPAuth does not work with IP/ICMP) which 622 would increase the likelihood of IETF-TDB-ND-4 (Default router is 623 killed) or IETF-TDB-ND-5 (Good router goes bad) threats being 624 exploited. Since there is no widely-accepted mitigation for any of 625 the three threats, this convoluted threat is laking a mitigation 626 solution as well. Fortunately, both complex threats could not be 627 validated empirically. An IPsec VPN connection was successfully 628 established using UDP encapsulation between the Windows Host and the 629 Ubuntu Server. Moreover, the IETF-TDB-ND-4 and IETF-TDB-ND-5 could 630 not be validated empirically, as Asamap [asamap2014] does not accept 631 RA messages when IPv6 forwarding is enabled. 633 If the IETF-TDB-TCP-1 threat (SYN flood) is exploited from an 634 untrusted entry point, it increases the likelihood of a IETF-TDB- 635 ND-10 (ND Replay attacks) threat. This threat can be mitigated by 636 blocking packets with non-internal addresses from leaving the 637 network. Both the SYN flood attack and the Neighbor Advertisement 638 (NA) flooding attacks were staged successfully. 640 7. Double Translation Threat Model 642 The main difference between the Single translation case and the 643 double translation case is the need for an extra translation device 644 as part of the core network (Figure 5). Another important difference 645 would be that in the untrusted zone, the Customer device and Data 646 store would employ the same IP suite. 648 7.1. Decompose the Technology 650 A DFD for double translation transition technologies is presented in 651 Figure 5. The diagram represents a basic use case and includes a 652 minimal set of elements. 654 Domain A-IPvX ___ Core Dom ___ Domain B-IPvX 655 +----------+ IPvX( ,' `. IPvY ,' `. ) ============ 656 | Customer |-----(---| Tra |---->| Tra |--- )-----> Provider 657 | Device |<----(----\ nsl /<------\ nsl /<----)------ Data Store 658 +----------+ ( `---' IPvY `---' IPvX) ============ 659 E P E P E P E P 660 _____________________________________________________________________ 661 Legend ___ Trust 662 +----------+ ,' `. ============ Data Flow () E=Entry 663 | External | | Pro | Data store ------------> () point 664 | Entity | \ cess/ ============ () P=Protected 665 +----------+ `---' boundary 667 Figure 5. DFD for 2transl technologies 669 7.2. Identify the threats 671 The considered threats for the untrusted elements would be either the 672 IPv4 suite (Table 6) or the IPv6 suite (Table 7) protocol threats. 673 Similar to the single translation technologies, the routing 674 (Table 10), switching (Table 5), transport layer (Table 9) and IP/ 675 ICMP (Table 8) threats should be analyzed as well. 677 The use of stateful translation mechanisms can expose a double 678 translation technology to the IETF-TDB-IP/ICMP-4 threat (DoS by 679 exhaustion of resources). A convoluted threat can result by 680 exploiting this threat on one of the translators and the IETF-TDB- 681 ND-4 or IETF-TDB-ND-5 threats on the other translator. This threat 682 would have a higher likelihood of exploitation since it is associated 683 with an untrusted entry point. In terms of mitigation, further 684 investigation is needed, as there are no widely accepted mitigation 685 techniques. Although the IETF-TDB-IP/ICMP-4 threat was replicated 686 with success, the IETF-TDB-ND-10 or IETF-TDB-ND-5 could not be 687 emulated because of a simple built-in mitigation mechanism 688 implemented by Asamap [asamap2014]. Router advertisement (RA) 689 messages are not accepted while in IPv6 forwarding mode. 691 The IETF-TDB-IP/ICMP-4 threat can also fuse with the simple 692 authentication threats such as IETF-TDB-OSPFv3-1 , IETF-TDB-OSPFv2-1 693 or IETF-TDB-RIPv2-1 to affect both translating nodes. The likelihood 694 of the threats become higher by fusing them, since the flooding 695 attack can be performed from an untrusted entry point, the customer 696 network. This threat could be mitigated by using cryptographic 697 authentication or implementing reverse path checks. The convoluted 698 threat was validated by flooding the translation table of the first 699 translator and forcing it to crash. OSPFv3 information disclosure 700 was emulated with simple traffic analysis. To validate the other 701 types of threats, a rogue router instance was created using Asamap 702 [asamap2014]. 704 8. Encapsulation Threat Model 706 Similar to double translation IPv6 transition technologies, 707 encapsulation technologies, the core network traffic is forwarded 708 through at least two devices, an Encapsulator and a Decapsulator 709 (Figure 6). As the main difference, the traffic is encapsulated. 710 This means more overhead but also more support for end-to-end 711 security protocols. Packets are encapsulated either over IPv4 or 712 IPv6. 714 8.1. Decompose the Technology 716 A DFD for encapsulation transition technologies is presented in 717 Figure 6. The diagram represents a basic use case and includes a 718 minimal set of elements. 720 Domain A-IPvX ___ Core Dom ___ Domain B-IPvX 721 +----------+ IPvX( ,' `. IPvY ,' `. ) ============ 722 | Customer |-----(---| Enc |---->| Dec |---- )-----> Provider 723 | Device |<----(----\ aps /<------\ aps /<-----)------ Data Store 724 +----------+ ( `---' IPvY `---' IPvX ) ============ 725 E P E P E P E P 726 _____________________________________________________________________ 727 Legend ___ Trust 728 +----------+ ,' `. ============ Data Flow {) E=Entry 729 | External | | Pro | Data store ------------> {) point 730 | Entity | \ cess/ ============ {) P=Protected 731 +----------+ `---' boundary 733 Figure 6. DFD for encaps technologies 735 8.2. Identify the threats 737 For the untrusted domain devices we would consider either the IPv4 738 suite (Table 6) or the IPv6 suite (Table 7) threats. In addition the 739 routing (Table 10), switching (Table 5), transport layer (Table 9) 740 and encapsulation-related (Table 8) threats should be considered. 742 Convoluted threats can arise by exploiting the IETF-TDB-4encaps-1 743 threat (avoiding IPv4 network security measures with encapsulation). 744 This threat can facilitate IPv6 suite DoS threats on the Decapsulator 745 device. This convoluted threat would increase the likelihood of a 746 successful DoS attack from the Customer Device. The threat could be 747 mitigated by making use of an IPv4 firewall before decapsulating the 748 packets. 750 9. Acknowledgments 752 The author would like to thank Fernando Gont for his review and 753 useful suggestions. 755 This document was derrived from a template contributed by the xml2rfc 756 project. 758 10. IANA Considerations 760 This memo includes no request to IANA. 762 All drafts are required to have an IANA considerations section (see 763 Guidelines for Writing an IANA Considerations Section in RFCs 764 [RFC5226] for a guide). If the draft does not require IANA to do 765 anything, the section contains an explicit statement that this is the 766 case (as above). If there are no requirements for IANA, the section 767 will be removed during conversion into an RFC by the RFC Editor. 769 11. Security Considerations 771 This memo attempts to build a threat model for IPv6 transition 772 technologies. The author would like to encourage the use of a 773 similar threat modeling approach when writing the security 774 considerations of standards developed in the IETF. To be more 775 concrete the following steps could be reused: 777 R1 Identify the function 779 R2 Associate the technology with a generic category (if any) 781 R3 Decompose the technology 782 R4 Identify the threats 784 R5 Review, repeat and validate 786 12. References 788 12.1. Normative References 790 [draft-bmwg-v6trans] 791 Georgescu, M. and G. Lencse, "Benchmarking Methodology for 792 IPv6 Transition Technologies", 2015, 793 . 796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", BCP 14, RFC 2119, 798 DOI 10.17487/RFC2119, March 1997, 799 . 801 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 802 Co-existence Security Considerations", RFC 4942, 803 DOI 10.17487/RFC4942, September 2007, 804 . 806 12.2. Informative References 808 [arps] Abad, C. and R. Bonilla, "An analysis on the schemes for 809 detecting and preventing ARP cache poisoning attacks", 810 2007. 812 [asamap2014] 813 Asama, M., "MAP supported Vyatta", 2014, 814 . 816 [bellovin89] 817 Bellovin, S., "Security Problems in the TCP/IP Protocol 818 Suite", 1989. 820 [harris99] 821 Harris, B. and R. Hunt, "TCP/IP security threats and 822 attack methods", 1999. 824 [icmps] Low, C., "ICMP attacks illustrated", 2001. 826 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 827 DOI 10.17487/RFC2328, April 1998, 828 . 830 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 831 DOI 10.17487/RFC2629, June 1999, 832 . 834 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 835 Text on Security Considerations", BCP 72, RFC 3552, 836 DOI 10.17487/RFC3552, July 2003, 837 . 839 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 840 Neighbor Discovery (ND) Trust Models and Threats", 841 RFC 3756, DOI 10.17487/RFC3756, May 2004, 842 . 844 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 845 "SEcure Neighbor Discovery (SEND)", RFC 3971, 846 DOI 10.17487/RFC3971, March 2005, 847 . 849 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 850 for IPv6 Hosts and Routers", RFC 4213, 851 DOI 10.17487/RFC4213, October 2005, 852 . 854 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 855 Control Message Protocol (ICMPv6) for the Internet 856 Protocol Version 6 (IPv6) Specification", RFC 4443, 857 DOI 10.17487/RFC4443, March 2006, 858 . 860 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 861 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 862 . 864 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 865 Authentication", RFC 4822, DOI 10.17487/RFC4822, February 866 2007, . 868 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 869 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 870 DOI 10.17487/RFC5226, May 2008, 871 . 873 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 874 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 875 January 2010, . 877 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 878 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 879 DOI 10.17487/RFC6052, October 2010, 880 . 882 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 883 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 884 . 886 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 887 NAT64: Network Address and Protocol Translation from IPv6 888 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 889 April 2011, . 891 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 892 China Education and Research Network (CERNET) IVI 893 Translation Design and Deployment for the IPv4/IPv6 894 Coexistence and Transition", RFC 6219, 895 DOI 10.17487/RFC6219, May 2011, 896 . 898 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 899 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 900 . 902 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 903 Stack Lite Broadband Deployments Following IPv4 904 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 905 . 907 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 908 Combination of Stateful and Stateless Translation", 909 RFC 6877, DOI 10.17487/RFC6877, April 2013, 910 . 912 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 913 Farrer, "Lightweight 4over6: An Extension to the Dual- 914 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 915 July 2015, . 917 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 918 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 919 Port with Encapsulation (MAP-E)", RFC 7597, 920 DOI 10.17487/RFC7597, July 2015, 921 . 923 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 924 and T. Murakami, "Mapping of Address and Port using 925 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 926 2015, . 928 [stride-shostack] 929 Shostack, A., "Experiences threat modeling at microsoft", 930 2008, . 933 [sws] Rouiller, S., "Virtual LAN Security: weaknesses and 934 countermeasures", 2003. 936 [udps] Garg, A. and A. Reddy, "Mitigation of DoS attacks through 937 QoS regulation", 2004. 939 [x1037] ITU-T, "IPv6 technical security guidelines. Recommendation 940 X.1037", 2013, . 942 Appendix A. Appendix A 943 Table5. L2 Technologies Threats 945 +---+----------+---------------+---+---+---+---+---+---+----------+ 946 | | ThreatID | Description | S | T | R | I | D | E |Mitigation| 947 +---+----------+---------------+---+---+---+---+---+---+----------+ 948 | 1 | | Exhaust | | | | | L | | IEEE | 949 | | IETF-TDB | a the FIB | | | | | | | 802.1x | 950 | | -VLAN-1 | of an | | | | | | | authen | 951 | | [x1037] | L2switch | | | | | | | tication | 952 +---+----------+---------------+---+---+---+---+---+---+----------+ 953 | 2 | | | | | | | L | | port | 954 | | IETF-TDB | CAM | | | | | | | -security| 955 | | -VLAN-2 | Overflow | | | | | | | features | 956 | | [sws] | | | | | | | | | 957 +---+----------+---------------+---+---+---+---+---+---+----------+ 958 | 3 | IETF-TDB | Basic | L | | | | | | Software | 959 | | -VLAN-3 | VLAN | | | | | | | update | 960 | | [sws] | Hopping | | | | | | | | 961 +---+----------+---------------+---+---+---+---+---+---+----------+ 962 | 4 | IETF-TDB | Double | L | | | | | L | Disable | 963 | | -VLAN-4 | encapsulation | | | | | | | Auto | 964 | | [sws] | VLAN | | | | | | | -trunking| 965 | | | Hopping | | | | | | | | 966 +---+----------+---------------+---+---+---+---+---+---+----------+ 967 | 5 | IETF-TDB | Spanning | | | | L | L | | Disable | 968 | | -VLAN-5 | Tree | | | | | | | STP; | 969 | | [sws] | Attack | | | | | | | BPDU | 970 | | | | | | | | | | Guard | 971 +---+----------+---------------+---+---+---+---+---+---+----------+ 972 | Legend | | 973 +---------------+-------------------------------------------------+ 974 | H | associaced with | | L | associaced with | 975 | | High likelihood | | | Low likelihood | 976 +---+----------------------------+-------+---+--------------------+ 978 Table6. IPv4 Protocol Suite Threats 980 +----+--------------+------------+---+---+---+---+---+---+----------+ 981 | | ThreatID | Description| S | T | R | I | D | E |Mitigation| 982 +----+--------------+------------+---+---+---+---+---+---+----------+ 983 | 1 | IETF-TDB | IP source | H | H | H | H | | | Apply | 984 | | -IPv4-1 | address | | | | | | | ACLs | 985 | | [harris99] | spoofing | | | | | | | filter | 986 | | | | | | | | | | source | 987 | | | | | | | | | | address | 988 | | | | | | | | | | traffic | 989 +----+--------------+------------+---+---+---+---+---+---+----------+ 990 | 2 | IETF-TDB | Mal | | H | | | | | Version | 991 | | -IPv4-2 | formed | | | | | | | checked | 992 | | [RFC6274] | version | | | | | | | to be 4 | 993 | | | field | | | | | | | | 994 | | | | | | | | | | | 995 +----+--------------+------------+---+---+---+---+---+---+----------+ 996 | 3 | IETF-TDB | forged | H | | | | H | | Filter | 997 | | -IPv4-3 | DSCP | | | | | | | unrecogn | 998 | | [RFC6274] | field | | | | | | | ized | 999 | | | | | | | | | | DSCP | 1000 +----+--------------+------------+---+---+---+---+---+---+----------+ 1001 | 4 | IETF-TDB | Buffer | | | | | H | | avoid | 1002 | | -IPv4-4 | overflow | | | | | | | illegit | 1003 | | [RFC6274] | IP frag | | | | | | | imate | 1004 | | | mentation | | | | | | | re | 1005 | | | | | | | | | | assembly | 1006 +----+--------------+------------+---+---+---+---+---+---+----------+ 1007 | 5 | IETF-TDB | Ping | | | | | H | | do not | 1008 | | -ICMP-1 | o'death | | | | | | | accept | 1009 | | [harris99] | | | | | | | | oversized| 1010 | | | | | | | | | | ICMP | 1011 +----+--------------+------------+---+---+---+---+---+---+----------+ 1012 | 6 | IETF-TDB | ICMP | H | H | H | H | H | | don't | 1013 | | -ICMP-2 | redirects | | | | | | | update | 1014 | | [bellovin89] | | | | | | | | routing | 1015 | | | | | | | | | | tables | 1016 | | | | | | | | | | with | 1017 | | | | | | | | | | ICMP | 1018 | | | | | | | | | | Redirects| 1019 +----+--------------+------------+---+---+---+---+---+---+----------+ 1020 | 7 | IETF-TDB | ICMP | | | | H | | | Selective| 1021 | | -ICMP-3 | sweep | | | | | | | filtering| 1022 | | [icmps] | for recon | | | | | | | of ICMP | 1023 | | | | | | | | | | | 1024 +----+--------------+------------+---+---+---+---+---+---+----------+ 1025 | 8 | IETF-TDB | ICMP | | | | | H | | Selective| 1026 | | -ICMP-6 | flooding | | | | | | | filtering| 1027 | | [icmps] | | | | | | | | of ICMP | 1028 +----+--------------+------------+---+---+---+---+---+---+----------+ 1029 | 9 | IETF-TDB | ARP | H | H | H | H | H | | Static | 1030 | | -ARP-1 | cache | | | | | | | ARP | 1031 | | [arps] | poisoning | | | | | | | entries, | 1032 | | | | | | | | | | arpwatch | 1033 +----+--------------+------------+---+---+---+---+---+---+----------+ 1034 | 10 | IETF-TDB | ARP | | | | | H | | Selective| 1035 | | -ARP-2 | cache | | | | | | | drop of | 1036 | | [RFC6274] | overrun | | | | | | | packets | 1037 | | | | | | | | | | | 1038 +----+--------------+------------+---+---+---+---+---+---+----------+ 1039 Table7. IPv6 Protocol Suite Threats 1041 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1042 | | ThreatID | Description | S | T | R | I | D | E | Mitigation| 1043 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1044 | 1 | IETF-TDB | Routing | H | | | | H | | Access | 1045 | | -IPv6-1 | header | | | | | | | controls | 1046 | | [RFC4942] | to evade | | | | | | | based on | 1047 | | | access | | | | | | | dest | 1048 | | | controls | | | | | | | addresses | 1049 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1050 | 2 | IETF-TDB | Site-scope | | | | H | | | Drop | 1051 | | -IPv6-2 | multicast | | | | | | | packets | 1052 | | [RFC4942] | addresses | | | | | | | with | 1053 | | | reconnaiss | | | | | | | site-scope| 1054 | | | ance | | | | | | | dest | 1055 | | | | | | | | | | addresses | 1056 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1057 | 3 | IETF-TDB | Anycast | | | | H | | | Restrict | 1058 | | -IPv6-3 | traffic | | | | | | | outside | 1059 | | [RFC4942] | identif | | | | | | | anycast | 1060 | | | reconnaiss | | | | | | | services | 1061 | | | ance | | | | | | | | 1062 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1063 | 4 | IETF-TDB | Extension | | | | | H | | Drop | 1064 | | -IPv6-4 | headers | | | | | | | packets | 1065 | | [RFC4942] | excessive | | | | | | | with | 1066 | | | hop-by-hop | | | | | | | unknown | 1067 | | | options | | | | | | | options | 1068 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1069 | 5 | IETF-TDB | Overuse | | | | | H | | Filter | 1070 | | -IPv6-5 | of IPv6 | | | | | | | externally| 1071 | | [RFC4942] | router alert | | | | | | | generated | 1072 | | | Option | | | | | | | Router | 1073 | | | | | | | | | | Alert | 1074 | | | | | | | | | | packets | 1075 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1076 | 6 | IETF-TDB | IPv6 | | | | | H | | Mandating | 1077 | | -IPv6-6 | fragmentation| | | | | | | the | 1078 | | [RFC4942] | overload of | | | | | | | size of | 1079 | | | reconstruct | | | | | | | packet | 1080 | | | buffers | | | | | | | fragments | 1081 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1082 | 7 | IETF-TDB | IPv4-Mapped | H | | | | H | | Avoid | 1083 | | -IPv6-7 | IPv6 | | | | | | | IPv4 | 1084 | | [RFC4942] | Addresses | | | | | | | -mapped | 1085 | | | | | | | | | | IPv6 | 1086 | | | | | | | | | | addesses | 1087 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1088 | 8 | IETF-TDB | ICMPv6 | H | | | | H | | IPAuth | 1089 | | -ICMPv6-1 | spoofing | | | | | | | | 1090 | | [RFC4443] | | | | | | | | | 1091 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1092 | 9 | IETF-TDB | ICMPv6 | H | | H | H | | | IPAuth | 1093 | | -ICMPv6-2 | Redirects | | | | | | | or ESP | 1094 | | [RFC4443] | | | | | | | | | 1095 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1096 | 10 | IETF-TDB | Back-to | | | | | H | | ICMP | 1097 | | -ICMPv6-3 | -back | | | | | | | error | 1098 | | [RFC4443] | erroneous | | | | | | | rate | 1099 | | | IP packets | | | | | | | limiting | 1100 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1101 | 11 | IETF-TDB | Send ICMP | | | | H | H | | Secure | 1102 | | -ICMPv6-4 | Parameter | | | | | | | multicast | 1103 | | [RFC4443] | Problem | | | | | | | traffic | 1104 | | | to multicast | | | | | | | | 1105 | | | source | | | | | | | | 1106 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1107 | 12 | IETF-TDB | ICMP | | | | | H | | IPSec | 1108 | | -ICMPv6-5 | passed to | | | | | | | | 1109 | | [RFC4443] | upper-layers | | | | | | | | 1110 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1111 | 14 | | Address | | | | | H | | Tune | 1112 | | IETF-TDB | Privacy | | | | | | | the change| 1113 | | -SLAAC-1 | Extensions | | | | | | | rate of | 1114 | | [RFC4942] | Interaction | | | | | | | the | 1115 | | | with DDoS | | | | | | | node | 1116 | | | Defenses | | | | | | | address | 1117 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1118 | 15 | IETF-TDB | NS/NA | H | | | | H | | SEND | 1119 | | -ND-1 | Spoofing | | | | | | | | 1120 | | [RFC3756] | | | | | | | | | 1121 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1122 | 16 | IETF-TDB | NUD | | | | | H | | SEND | 1123 | | -ND-2 | failure | | | | | | | | 1124 | | [RFC3756] | | | | | | | | | 1125 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1126 | 17 | IETF-TDB | Malicious | | | L | L | L | | SEND | 1127 | | -ND-3 | Last Hop | | | | | | | | 1128 | | [RFC3756] | Router | | | | | | | | 1129 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1130 | 18 | IETF-TDB | Default | | | L | L | L | | No widely | 1131 | | -ND-4 | router | | | | | | | accepted | 1132 | | [RFC3756] | is 'killed' | | | | | | | mitigation| 1133 | | | | | | | | | | technique | 1134 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1135 | 19 | IETF-TDB | Good | | | L | L | L | | No widely | 1136 | | -ND-5 | Router | | | | | | | accepted | 1137 | | [RFC3756] | Goes Bad | | | | | | | mitigation| 1138 | | | | | | | | | | technique | 1139 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1140 | 20 | IETF-TDB | Spoofed | | | L | L | L | | SEND; | 1141 | | -ND-6 | Redirect | | | | | | | Still an | 1142 | | [RFC3756] | Message | | | | | | | issue for | 1143 | | | | | | | | | | ad-hoc | 1144 | | | | | | | | | | cases | 1145 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1146 | 21 | IETF-TDB | Bogus | | | | | L | | SEND | 1147 | | -ND-7 | On-Link | | | | | | | | 1148 | | [RFC3756] | Prefix | | | | | | | | 1149 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1150 | 22 | IETF-TDB | Bogus | | | | | L | | SEND; | 1151 | | -ND-8 | Address | | | | | | | Still an | 1152 | | [RFC3756] | Config | | | | | | | issue for | 1153 | | | Prefix | | | | | | | ad-hoc | 1154 | | | | | | | | | | cases | 1155 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1156 | 23 | IETF-TDB | Parameter | L | | L | L | | | SEND; | 1157 | | -ND-9 | Spoofing | | | | | | | Still an | 1158 | | [RFC3756] | | | | | | | | issue for | 1159 | | | | | | | | | | ad-hoc | 1160 | | | | | | | | | | cases | 1161 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1162 | 24 | IETF-TDB | ND Replay | H | | | H | | | SEND | 1163 | | -ND-10 | attacks | | | | | | | | 1164 | | [RFC3756] | | | | | | | | | 1165 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1166 | 25 | IETF-TDB | Neighbor | | | | | H | | Rate limit| 1167 | | -ND-11 | Discovery | | | | | | | NS | 1168 | | [RFC3756] | DoS | | | | | | | messsages | 1169 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1170 | | IETF-TDB | | | | | | | | | 1171 | 26 | DAD_1 | DAD | | | | | H | | SEND | 1172 | | [RFC3756] | DoS | | | | | | | | 1173 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1174 | 27 | IETF-TDB | Authorization| | | | | H | | Cache | 1175 | | -SEND-1 | Delegation | | | | | | | discovered| 1176 | | [RFC3971] | Discovery | | | | | | | info | 1177 | | | DoS | | | | | | | and limit | 1178 | | | | | | | | | | the number| 1179 | | | | | | | | | | of | 1180 | | | | | | | | | | discovery | 1181 | | | | | | | | | | processes | 1182 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1183 | 28 | IETF-TDB | Obsolete | H | | | | | | Secure | 1184 | | -MIPv6-1 | Home | | | | | | | Binding | 1185 | | [RFC4942] | Address | | | | | | | Update | 1186 | | | Option | | | | | | | messages | 1187 | | | Mobile | | | | | | | | 1188 | | | IPv6 | | | | | | | | 1189 +----+-----------+--------------+---+---+---+---+---+---+-----------+ 1190 Table8. Basic Transition Technologies Threats 1192 +---+------------+-------------+---+---+---+---+---+---+-----------+ 1193 | | ThreatID | Description | S | T | R | I | D | E | Mitigation| 1194 +---+------------+-------------+---+---+---+---+---+---+-----------+ 1195 | 1 | IETF-TDB- | IPv4 | L | | | | | | Implement | 1196 | | IP/ICPM-1 | spoofing | | | | | | | reverse | 1197 | | [RFC6052] | with | | | | | | | path | 1198 | | | IPv4 | | | | | | | checks | 1199 | | | -embedded | | | | | | | | 1200 | | | IPv6 | | | | | | | | 1201 +---+------------+-------------+---+---+---+---+---+---+-----------+ 1202 | 2 | IETF-TDB | ESP | | | | L | | | Use | 1203 | | -IP/ICMP-2 | fails | | | | | | | checksum | 1204 | | [RFC6145] | with | | | | | | | -neutral | 1205 | | | IPv6 | | | | | | | addresses | 1206 | | | -to- | | | | | | | | 1207 | | | IPv4 | | | | | | | | 1208 | | | translation | | | | | | | | 1209 +---+------------+-------------+---+---+---+---+---+---+-----------+ 1210 | 3 | IETF-TDB | Auth | | | | L | | | No widely | 1211 | | -IP/ICMP-3 | Headers | | | | | | | accepted | 1212 | | [rfc6145] | cannot | | | | | | | mitigation| 1213 | | | be used | | | | | | | | 1214 | | | across | | | | | | | | 1215 | | | IPv6- | | | | | | | | 1216 | | | to-IPv4 | | | | | | | | 1217 +---+------------+-------------+---+---+---+---+---+---+-----------+ 1218 | 4 | IETF-TDB | Stateful | | | | | L | | No widely | 1219 | | -IP/ICMP-4 | translators | | | | | | | accepted | 1220 | | [RFC6145] | resources | | | | | | | mitigation| 1221 | | | exhaustion | | | | | | | | 1222 +---+------------+-------------+---+---+---+---+---+---+-----------+ 1223 | 5 | 4encaps_1 | Tunneling | | | | L | | | route | 1224 | | [RFC4942] | IPv6 over | | | | | | | encaps | 1225 | | | IPv4 breaks | | | | | | | traffic | 1226 | | | IPv4 | | | | | | | through | 1227 | | | Network's | | | | | | | IPv4 | 1228 | | | security | | | | | | | firewall | 1229 | | | assumptions | | | | | | | before | 1230 | | | | | | | | | | decaps | 1231 +---+------------+-------------+---+---+---+---+---+---+-----------+ 1233 Table9. L4 Technologies Threats 1235 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1236 | | ThreatID |Description| S | T | R | I | D | E |Mitigation| 1237 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1238 | 1 | IETF-TDB | SYN | | | | | H | | Block | 1239 | | -TCP-1 | flood | | | | | | | non- | 1240 | | [harris99] | | | | | | | | internal | 1241 | | | | | | | | | | addresses| 1242 | | | | | | | | | | from | 1243 | | | | | | | | | | leaving | 1244 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1245 | 2 | IETF-TDB | SYN | H | | H | | H | | L3/L4 | 1246 | | -TCP-2 | /ACK | | | | | | | Packet | 1247 | | [harris99] | flood | | | | | | | Filtering| 1248 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1249 | 3 | IETF-TDB | ACK or | H | | H | | H | | L3/L4 | 1250 | | -TCP-3 | ACK | | | | | | | Packet | 1251 | | [harris99] | -PUSH | | | | | | | Filtering| 1252 | | | Flood | | | | | | | | 1253 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1254 | 4 | IETF-TDB | Frag | | | | | H | | L3/L4 | 1255 | | -TCP-4 | mented | | | | | | | Packet | 1256 | | [harris99] | ACK | | | | | | | Filtering| 1257 | | | Flood | | | | | | | | 1258 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1259 | 5 | IETF-TDB | TCP | H | | | | | | Block | 1260 | | -TCP-5 | Spoofing | | | | | | | non | 1261 | | [harris99] | sequence | | | | | | | -internal| 1262 | | | number | | | | | | | traffic | 1263 | | | prediction| | | | | | | from | 1264 | | | | | | | | | | leaving | 1265 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1266 | 6 | IETF-TDB | TCP | H | H | H | H | H | H | Block | 1267 | | -TCP-6 | session | | | | | | | non | 1268 | | [harris99] | hijacking | | | | | | | -internal| 1269 | | | sequence | | | | | | | traffic | 1270 | | | number | | | | | | | from | 1271 | | | prediction| | | | | | | leaving | 1272 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1273 | 7 | IETF-TDB | RST | | | | | H | | L3/L4 | 1274 | | -TCP-7 | and | | | | | | | Packet | 1275 | | [harris99] | FIN | | | | | | | Filtering| 1276 | | | DoS | | | | | | | Stateful | 1277 | | | | | | | | | | Flow | 1278 | | | | | | | | | | Awareness| 1279 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1280 | 8 | IETF-TDB | UDP | | | | | H | |QoS | 1281 | | -UDP-8 | flood | | | | | | |regulation| 1282 | | [udps] | | | | | | | |;L3/L4 | 1283 | | | | | | | | | |Packet | 1284 | | | | | | | | | |Filtering | 1285 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1286 | 9 | IETF-TDB | Port set | | | | | H | | Address | 1287 | | -NAT44-9 | exaustion | | | | | | | Dependent| 1288 | | [rfc7957] | | | | | | | | Filtering| 1289 +---+----------------+-----------+---+---+---+---+---+---+----------+ 1291 Table10. Routing Technologies Threats 1293 +---+-----------+----------------+---+---+---+---+---+---+----------+ 1294 | | ThreatID | Description | S | T | R | I | D | E |Mitigation| 1295 +---+-----------+----------------+---+---+---+---+---+---+----------+ 1296 | 1 | IETF-TDB | simple | L | L | L | L | L | L | crypto | 1297 | x | -RIPv2-1 | password | | | | | | | authen | 1298 | | [RFC4822] | authen | | | | | | | | 1299 +---+-----------+----------------+---+---+---+---+---+---+----------+ 1300 | 2 | IETF-TDB | simple | L | L | L | L | L | L | crypto | 1301 | x | -OSPFv2-1 | password | | | | | | | authen | 1302 | | [RFC2328] | authen | | | | | | | | 1303 +---+-----------+----------------+---+---+---+---+---+---+----------+ 1304 | 3 | IETF-TDB | OSPFv2 | L | L | L | L | L | L | crypto | 1305 | x | -OSPFv2-2 | authen | | | | | | | sequence | 1306 | | [RFC2328] | sequence | | | | | | | number | 1307 | | | number | | | | | | | | 1308 | | | prediction | | | | | | | | 1309 +---+-----------+----------------+---+---+---+---+---+---+----------+ 1310 | 4 | IETF-TDB | OSPFv3 | L | L | L | L | L | L | no | 1311 | | -OSPFv3-1 | using the | | | | | | | manual | 1312 | | [RFC4552] | same | | | | | | | keys | 1313 | | | manual | | | | | | | | 1314 | | | key | | | | | | | | 1315 +---+-----------+----------------+---+---+---+---+---+---+----------+ 1316 | Legend | | 1317 +---------------+---------------------------------------------------+ 1318 | H | associaced with | | L | associaced with | 1319 | | High likelihood | | | Low likelihood | 1320 +---+----------------------------+-------+---+----------------------+ 1322 Author's Address 1324 Marius Georgescu (editor) 1325 NAIST 1326 Takayama 8916-5 1327 Nara 630-0192 1328 Japan 1330 Phone: +81 743 72 5216 1331 Email: liviumarius-g@is.naist.jp 1332 URI: http://www.ipv6net.ro