idnits 2.17.1 draft-ietf-6man-predictable-fragment-id-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 (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 30, 2014) is 3649 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Updates: 2460 (if approved) April 30, 2014 5 Intended status: Best Current Practice 6 Expires: November 1, 2014 8 Security Implications of Predictable Fragment Identification Values 9 draft-ietf-6man-predictable-fragment-id-01 11 Abstract 13 IPv6 specifies the Fragment Header, which is employed for the 14 fragmentation and reassembly mechanisms. The Fragment Header 15 contains an "Identification" field which, together with the IPv6 16 Source Address and the IPv6 Destination Address of a packet, 17 identifies fragments that correspond to the same original datagram, 18 such that they can be reassembled together at the receiving host. 19 The only requirement for setting the "Identification" value is that 20 it must be different than that employed for any other fragmented 21 packet sent recently with the same Source Address and Destination 22 Address. Some implementations use simple a global counter for 23 setting the Identification field, thus leading to predictable values. 24 This document analyzes the security implications of predictable 25 Identification values, and updates RFC 2460 specifying additional 26 requirements for setting the Identification field of the Fragment 27 Header, such that the aforementioned security implications are 28 mitigated. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 1, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Security Implications of Predictable Fragment Identification 67 values . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Updating RFC 2460 . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Constraints for the selection of Fragment Identification 70 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Algorithms for Selecting Fragment Identification Values . . . 7 72 6.1. Per-destination counter (initialized to a random value) . 7 73 6.2. Randomized Identification values . . . . . . . . . . . . 8 74 6.3. Hash-based Fragment Identification selection algorithm . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 10.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Appendix A. Information leakage produced by vulnerable 82 implementations . . . . . . . . . . . . . . . . . . 13 83 Appendix B. Survey of Fragment Identification selection 84 algorithms employed by popular IPv6 implementations 15 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 IPv6 specifies the Fragment Header, which is employed for the 90 fragmentation and reassembly mechanisms. The Fragment Header 91 contains an "Identification" field which, together with the IPv6 92 Source Address and the IPv6 Destination Address of a packet, 93 identifies fragments that correspond to the same original datagram, 94 such that they can be reassembled together at the receiving host. 96 The only requirement for setting the "Identification" value is that 97 it must be different than that employed for any other fragmented 98 packet sent recently with the same Source Address and Destination 99 Address. 101 The most trivial algorithm to avoid reusing Fragment Identification 102 values too quickly is to maintain a global counter that is 103 incremented for each fragmented packet that is transmitted. However, 104 this trivial algorithm leads to predictable Identification values, 105 which can be leveraged to performing a variety of attacks. 107 Section 3 of this document analyzes the security implications of 108 predictable Identification values. Section 4 updates RFC 2460 by 109 adding the requirement that IPv6 Fragment Identification values must 110 not be predictable by an off-path attacker. Section 5 discusses 111 constraints in the possible algorithms for selecting Fragment 112 Identification values. Section 6 specifies a number of algorithms 113 that could be used for generating Identification values. Finally, 114 Appendix B contains a survey of the Fragment Identification 115 algorithms employed by popular IPv6 implementations. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Security Implications of Predictable Fragment Identification values 125 Predictable Identification values result in an information leakage 126 that can be exploited in a number of ways. Among others, they may 127 potentially be exploited to: 129 o determine the packet rate at which a given system is transmitting 130 information, 132 o perform stealth port scans to a third-party, 134 o uncover the rules of a number of firewalls, 136 o count the number of systems behind a middle-box, 138 o perform Denial of Service (DoS) attacks, or, 140 o perform data injection attacks against transport or application 141 protocols 143 [CPNI-IPv6] contains a detailed analysis of possible vulnerabilities 144 introduced by predictable Fragment Identification values. In 145 summary, their security implications are very similar to those of 146 predictable Identification values in IPv4. 148 [Sanfilippo1998a] originally pointed out how the IPv4 149 Identification field could be examined to determine the packet 150 rate at which a given system is transmitting information. Later, 151 [Sanfilippo1998b] describes how a system with such an 152 implementation could be used to perform a stealth port scan to a 153 third (victim) host. [Sanfilippo1999] explains how to exploit 154 this implementation strategy to uncover the rules of a number of 155 firewalls. [Bellovin2002] explains how the IPv4 Identification 156 field can be exploited to count the number of systems behind a 157 NAT. [Fyodor2004] is an entire paper on most (if not all) the 158 ways to exploit the information provided by the Identification 159 field of the IPv4 header (and these results apply in a similar way 160 to IPv6). [Zalewski2003] originally envisioned the exploitation 161 of IP fragmentation for performing data injection attacks against 162 upper-layer protocols. [Herzberg2013] explores the use of IPv4/ 163 IPv6 fragmentation and predictable Identification values for 164 performing DNS cache poisoning attacks in great detail. [RFC6274] 165 covers the security implications of the IPv4 case in detail. 167 One key difference between the IPv4 case and the IPv6 case is that in 168 IPv4 the Identification field is part of the fixed IPv4 header (and 169 thus usually set for all packets), while in IPv6 the Identification 170 field is present only in those packets that carry a Fragment Header. 171 As a result, successful exploitation of the IPv6 Fragment 172 Identification field depends on two different factors: 174 o vulnerable IPv6 Fragment Identification generators, and, 176 o the ability of an attacker to trigger the use of IPv6 177 fragmentation for packets sent from/to the victim node 179 As noted in the previous section, some implementations have been 180 known to use predictable Fragment Identification values. For 181 instance, Appendix B of this document shows that recent versions of a 182 number of popular IPv6 implementations have employed predictable 183 values for the IPv6 Fragment Identification. 185 Additionally, we note that RFC 1981 [RFC1981] states that when an 186 ICMPv6 Packet Too Big error message advertising an MTU smaller than 187 1280 bytes is received, the receiving host is not required to reduce 188 the Path-MTU for the corresponding destination address, but must 189 simply include a Fragment Header in all subsequent packets sent to 190 that destination. This triggers the use of the so-called IPv6 191 "atomic fragments" [RFC6946]: IPv6 fragments with a Fragment Offset 192 equal to 0, and the "M" ("More fragments") bit clear. 194 Thus, an attacker can usually cause a victim host to "fragment" its 195 outgoing packets by sending it a forged ICMPv6 'Packet Too Big' (PTB) 196 error message that advertises a Next-Hop MTU smaller than 1280 bytes. 198 There are a number of aspects that should be considered, though: 200 o All the implementations the author is aware of record the Path-MTU 201 information on a per-destination basis. Thus, an attacker can 202 only cause the victim to enable fragmentation for those packets 203 sent to the Source Address of IPv6 packet embedded in the payload 204 of the ICMPv6 PTB message. However, we note that Section 5.2 of 205 [RFC1981] notes that an implementation could maintain a single 206 system-wide PMTU value to be used for all packets originating from 207 that nodes. Clearly, such an implementations would exacerbate the 208 problem of any attacks based on PMTUD [RFC5927] or IPv6 209 fragmentation. 211 o If the victim node implements some of the counter-measures for 212 ICMP attacks described in RFC 5927 [RFC5927], it might be 213 difficult for an attacker to cause the victim node to use 214 fragmentation for its outgoing packets. However, many current 215 implementations fail to enforce these validation checks. For 216 example, Linux 2.6.38-8 does not even require received ICMPv6 217 error messages to correspond to ongoing communication instances. 219 Implementations that employ predictable Identification values and 220 also fail to enforce validation checks on ICMPv6 error messages 221 become vulnerable to the same type of attacks that can be exploited 222 with IPv4 fragmentation, discussed earlier in this section. 224 One possible way in which predictable Identification values could be 225 leveraged for performing a Denial of Service (DoS) attack is as 226 follows: Let us assume that Host A is communicating with Host B, and 227 that an attacker wants to DoS such communication. The attacker would 228 learn the the Identification value currently in use by Host A, 229 possibly by sending any packet that would elicit a fragmented 230 response (e.g., an ICCPMv6 echo request with a large payload). The 231 attacker would then send a forged ICMPv6 Packet Too Big error message 232 to Host A (with the IPv6 Destination Address of the embedded IPv6 233 packet set to the IPv6 address of a Host B), such that any subsequent 234 packets sent by Host A to Host B include a Fragment Header. Finally, 235 the attacker send forged IPv6 fragments to the Host B, with their 236 IPv6 Source Address set to that of Host A, and Identification values 237 that would result in collisions with the Identification values 238 employed for the legitimate traffic sent by Host A to Host B. If Host 239 B discards fragments that result in collisions of Identification 240 values (e.g., such fragments overlap, and the host implements 241 [RFC5722]), the attacker could simply trash the Identification space 242 by sending multiple forged fragments with different Identification 243 values, such that any subsequent packets from Host A to Host B are 244 discarded at Host B as a result of the malicious fragments sent by 245 the attacker. 247 NOTES: 249 For example, Linux 2.6.38-10 is vulnerable to the aforementioned 250 issue. 252 [RFC6946] describes an improved processing of these packets that 253 would eliminate this specific attack vector, at least in the case 254 of TCP connections that employ the Path-MTU Discovery mechanism. 256 The previous attack scenario is simply included to illustrate the 257 problem of employing predictable fragment Identification values. We 258 note that regardless of the attacker's ability to cause a victim host 259 to employ fragmentation when communicating with third-parties, use of 260 predictable Identification values makes communication flows that 261 employ fragmentation vulnerable to any fragmentation-based attacks. 263 4. Updating RFC 2460 265 Hereby we update RFC 2460 [RFC2460] as follows: 267 The Identification value of the Fragment Header MUST NOT be 268 predictable by an off-path attacker. 270 5. Constraints for the selection of Fragment Identification Values 272 The "Identification" field of the Fragmentation Header is 32-bits 273 long. However, when translators [RFC6145] are employed, the 274 "effective" length of the IPv6 Fragment Identification field is 16 275 bits. 277 NOTE: [RFC6145] notes that, when translating in the IPv6-to-IPv4 278 direction, "if there is a Fragment Header in the IPv6 packet, the 279 last 16 bits of its value MUST be used for the IPv4 identification 280 value". This means that the high-order 16 bits are effectively 281 ignored. 283 As a result, at least during the IPv6/IPv4 transition/co-existence 284 phase, it is probably safer to assume that only the low-order 16 bits 285 of the IPv6 Fragment Identification are of use to the destination 286 system. 288 Regarding the selection of Fragment Identification values, the only 289 requirement specified in [RFC2460] is that the Fragment 290 Identification must be different than that of any other fragmented 291 packet sent recently with the same Source Address and Destination 292 Address. Failure to comply with this requirement could lead to the 293 interoperability problems discussed in [RFC4963]. 295 From a security standpoint, unpredictable Identification values are 296 desirable. However, this is somewhat at odds with the "re-use" 297 requirements specified in [RFC2460]. 299 Finally, since Fragment Identification values need to be selected for 300 each outgoing datagram that requires fragmentation, the performance 301 aspect should be considered when choosing an algorithm for the 302 selection of Fragment Identification values. 304 6. Algorithms for Selecting Fragment Identification Values 306 This section specifies a number of algorithms that MAY be used for 307 selecting Fragment Identification values. 309 6.1. Per-destination counter (initialized to a random value) 311 1. Whenever a packet must be sent with a Fragment Header, the 312 sending host should perform a look-up in the Destinations Cache 313 an entry corresponding to the Destination Address of the packet. 315 2. If such an entry exists, it contains the last Fragment 316 Identification value used for that Destination. Therefore, such 317 value should be incremented by 1, and used for setting the 318 Fragment Identification value of the outgoing packet. 319 Additionally, the updated value should be recorded in the 320 corresponding entry of the Destination Cache. 322 3. If such an entry does not exist, it should be created, and the 323 "Identification" value for that destination should be initialized 324 with a random value (e.g., with a pseudorandom number generator), 325 and used for setting the Identification field of the Fragment 326 Header of the outgoing packet. 328 The advantages of this algorithm are: 330 o It is simple to implement, with the only complexity residing in 331 the Pseudo-Random Number Generator (PRNG) used to initialize the 332 "Identification" value contained in each entry of the Destinations 333 Cache. 335 o The "Identification" re-use frequency will typically be lower than 336 that achieved by a global counter (when sending traffic to 337 multiple destinations), since this algorithm uses per-destination 338 counters (rather than a single system-wide counter). 340 o It has good performance properties (once the corresponding entry 341 in the Destinations Cache has been created, each subsequent 342 "Identification" value simply involves the increment of a 343 counter). 345 The possible drawbacks of this algorithm are: 347 o If as a result of resource management an entry of the Destinations 348 Cache must be removed, the last Fragment Identification value used 349 for that Destination will be lost. Thus, subsequent traffic to 350 that destination would cause that entry to be re-created and re- 351 initialized to random value, thus possibly leading to Fragment 352 Identification "collisions". 354 o Since the Fragment Identification values are predictable by the 355 destination host, a vulnerable host might possibly leak to third- 356 parties the Fragment Identification values used by other hosts to 357 send traffic to it (i.e., Host B could leak to Host C the Fragment 358 Identification values that Host A is using to send packets to Host 359 B). Appendix A describes one possible scenario for such leakage 360 in detail. 362 6.2. Randomized Identification values 364 Clearly, use of a Pseudo-Random Number Generator for selecting the 365 Fragment Identification would be desirable from a security 366 standpoint. With such a scheme, the Fragment Identification of each 367 fragmented datagram would be selected as: 369 Identification = random() 371 where "random()" is the PRNG. 373 The specific properties of such scheme would clearly depend on the 374 specific PRNG algorithm used. For example, some PRNGs may result in 375 higher Fragment Identification reuse frequencies than others, in the 376 same way as some PRNGs may be more expensive (in terms of processing 377 requirements and/or implementation complexity) than others. 379 Discussion of the properties of possible PRNGs is considered out of 380 the scope of this document. However, we do note that some PRNGs 381 employed in the past by some implementations have been found to be 382 predictable [Klein2007]. Please see [RFC4086] for randomness 383 requirements for security. 385 6.3. Hash-based Fragment Identification selection algorithm 387 Another alternative is to implement a hash-based algorithm similar to 388 that specified in [RFC6056] for the selection of transport port 389 numbers. With such a scheme, the Fragment Identification value of 390 each fragment datagram would be selected with the expression: 392 Identification = F(Src IP, Dst IP, secret1) + 393 counter[G(src IP, Dst Pref, secret2)] 395 where: 397 Identification: 398 Identification value to be used for the fragmented datagram 400 F(): 401 Hash function 403 Src IP: 404 IPv6 Source Address of the datagram to be fragmented 406 Dst IP: 407 IPv6 Destination Address of the datagram to be fragmented 409 secret1: 410 Secret data unknown to the attacker 412 counter[]: 413 System-wide array of 32-bit counters (e.g. with 8K elements or 414 more) 416 G(): 417 Hash function. May or may not be the same hash function as that 418 used for F() 420 Dst Pref: 421 IPv6 "Destination Prefix" of datagram to be fragmented (can be 422 assumed to be the first eight bytes of the Destination Address of 423 such packet). Note: the "Destination Prefix" (rather than 424 Destination Address) is used, such that the ability of an attacker 425 of searching the "increments" space by using multiple addresses of 426 the same subnet is reduced. 428 secret1: 429 Secret data unknown to the attacker 431 NOTE: counter[G(src IP, Dst Pref, secret2)] should be incremented by 432 one each time an Identification value is selected. 434 The advantages of this algorithm are: 436 o The "Identification" re-use frequency will typically be lower than 437 that achieved by a global counter (when sending traffic to 438 multiple destinations), since this algorithm uses multiple system- 439 wide counters (rather than a single system-wide counter). The 440 extent to which the re-use frequency will be lower will depend on 441 the number of elements in counter[], and the number of other 442 active flows that result in the same value of G() (and hence cause 443 the same counter to be incremented for each fragmented datagram 444 that is sent). 446 o It is possible to implement the algorithm such that good 447 performance is achieved. For example, the result of F() could be 448 stored in the Destinations Cache (such that it need not be 449 recomputed for each packet that must be sent) along with the 450 computed "index"/argument for counter[]. 452 NOTE: If this implementation approach is followed, and an entry 453 of the Destinations Cache must be removed as a result of 454 resource management, the last Fragment Identification value 455 used for that Destination will *not* lost. This is an 456 improvement over the algorithm specified in Section 6.1. 458 The possible drawbacks of this algorithm are: 460 o Since the Fragment Identification values are predictable by the 461 destination host, a vulnerable host could possibly leak to third- 462 parties the Fragment Identification values used by other hosts to 463 send traffic to it (i.e., Host B could leak to Host C the Fragment 464 Identification values that Host A is using to send packets to Host 465 B). Appendix A describes a possible scenario in which that 466 information leakage could take place. We note, however, that this 467 algorithm makes the aforementioned attack less reliable for the 468 attacker, since each counter could be possibly shared by multiple 469 traffic flows (i.e., packets destined to other destinations might 470 cause the same counter to be incremented). 472 This algorithm might be preferable (over the one specified in 473 Section 6.1) in those scenarios in which a node is expected to 474 communicate with a large number of destinations, and thus it is 475 desirable to limit the amount of information to be maintained in 476 memory. 478 NOTE: In such scenarios, if the algorithm specified in Section 6.1 479 were implemented, entries from the Destinations Cache might need 480 to be pruned frequently, thus increasing the risk of fragment 481 Identification collisions. 483 7. IANA Considerations 485 There are no IANA registries within this document. The RFC-Editor 486 can remove this section before publication of this document as an 487 RFC. 489 8. Security Considerations 491 This document discusses the security implications of predictable 492 Fragment Identification values, and updates RFC 2460 such that 493 Fragment Identification values are required to be unpredictable by 494 off-path attackers, hence mitigating the aforementioned security 495 implications. 497 A number of possible algorithms are specified, to provide some 498 implementation alternatives to implementers. However, the selection 499 of a specific algorithm is left to implementers. We note that the 500 selection of such an algorithm usually implies a number of trade-offs 501 (security, performance, implementation complexity, interoperability 502 properties, etc.). 504 9. Acknowledgements 506 The author would like to thank Ivan Arce for proposing the attack 507 scenario described in Appendix A. 509 The author would like to thank Ivan Arce and Dave Thaler for 510 providing valuable comments on earlier versions of this document. 512 This document is based on the technical report "Security Assessment 513 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 514 Fernando Gont on behalf of the UK Centre for the Protection of 515 National Infrastructure (CPNI). 517 10. References 519 10.1. Normative References 521 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 522 for IP version 6", RFC 1981, August 1996. 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 528 (IPv6) Specification", RFC 2460, December 1998. 530 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 531 Requirements for Security", BCP 106, RFC 4086, June 2005. 533 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 534 RFC 5722, December 2009. 536 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 537 Protocol Port Randomization", BCP 156, RFC 6056, January 538 2011. 540 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 541 Algorithm", RFC 6145, April 2011. 543 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 544 6946, May 2013. 546 10.2. Informative References 548 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 549 Errors at High Data Rates", RFC 4963, July 2007. 551 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 553 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 554 Version 4", RFC 6274, July 2011. 556 [Bellovin2002] 557 Bellovin, S., "A Technique for Counting NATted Hosts", 558 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 560 [CPNI-IPv6] 561 Gont, F., "Security Assessment of the Internet Protocol 562 version 6 (IPv6)", UK Centre for the Protection of 563 National Infrastructure, (available on request). 565 [Fyodor2004] 566 Fyodor, , "Idle scanning and related IP ID games", 2004, 567 . 569 [Herzberg2013] 570 Herzberg, A. and H. Shulman, "Fragmentation Considered 571 Poisonous", Technical Report 13-03, March 2013, 572 . 574 [Klein2007] 575 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 576 Predictable IP ID Vulnerability", 2007, 577 . 580 [Sanfilippo1998a] 581 Sanfilippo, S., "about the ip header id", Post to Bugtraq 582 mailing-list, Mon Dec 14 1998, 583 . 585 [Sanfilippo1998b] 586 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 587 1998, . 589 [Sanfilippo1999] 590 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 591 list, 1999, 592 . 594 [SI6-IPv6] 595 "SI6 Networks' IPv6 toolkit", 596 . 598 [Zalewski2003] 599 Zalewski, M., "A new TCP/IP blind data injection 600 technique?", Post to Bugtraq mailing-list, Thu, 11 Dec 601 2003 00:28:28 +0100 (CET), 2003, 602 . 604 Appendix A. Information leakage produced by vulnerable implementations 606 Section 3 provides a number of references describing a number of ways 607 in which a vulnerable implementation may reveal the Fragment 608 Identification values to be used in subsequent packets, thus opening 609 the door to a number of attacks. In all of those scenarios, a 610 vulnerable implementation leaks/reveals its own Identification 611 number. 613 This section presents a different case, in which a vulnerable 614 implementation leaks/reveals the Identification number of a non- 615 vulnerable implementation. That is, a vulnerable implementation 616 (Host A) leaks the current Fragment Identification value in use by a 617 third-party host (Host B) to send fragmented datagrams from Host B to 618 Host A. 620 For the most part, this section is included to illustrate how a 621 vulnerable implementation might be leveraged to leak-out the 622 Fragment Identification value of an otherwise non-vulnerable 623 implementation. This section might be removed in future revisions 624 of this document. 626 The following scenarios assume: 628 Host A: 629 Is an IPv6 host that implements the recommended Fragment 630 Identification algorithm (Section 6.1), implements [RFC5722], but 631 does not implement [RFC6946]. 633 Host B: 634 Victim node. Selected the Fragment Identification values from a 635 global counter. 637 Host C: 638 Attacker. Can forge the IPv6 Source Address of his packets at 639 will. 641 In the following scenarios, large ICMPv6 Echo Request packets are 642 employed to "sample" the Fragment Identification value of a host. We 643 note that while the figures show only one packet for the ICMPv6 Echo 644 Request and the ICMPv6 Echo Response, each of those packets will 645 typically comprise two fragments, such that the resulting datagram is 646 larger than the MTU of the networks to which Host B and Host C are 647 attached. 649 In the lines #1-#2 (and lines #8-#9), the attacker samples the 650 current Fragment Identification value. In line #3, the attacker 651 sends a forged TCP SYN segment to Host A. If corresponding TCP port 652 is closed, and the attacker fails when trying to produce a collision 653 of Fragment Identifications (see line #4), the following packet 654 exchange might take place: 656 A B C 658 #1 <------ Echo Req #1 ----------- 659 #2 --- Echo Resp #1, FID=5000 ---> 660 #3 <------------------- SYN #1, src= B ----------------------- 661 #4 <--- SYN/ACK, FID=42 src = A--- 662 #5 ---- SYN/ACK, FID=9000 ---> 663 #6 <----- RST, FID= 5001 ----- 664 #7 <----- RST, FID= 5002 ----- 665 #8 <-------- Echo Req #2 --------- 666 #9 --- Echo Resp #2, FID=5003 ---> 667 On the other hand, if the attacker succeeds to produce a collision of 668 Fragment Identification values, the following packet exchange could 669 take place: 671 A B C 673 #1 <------- Echo Req #1 ---------- 674 #2 --- Echo Resp #1, FID=5000 ---> 675 #3 <------------------- SYN #1, src= B ----------------------- 676 #4 <-- SYN/ACK, FID=9000 src=A --- 677 #5 ---- SYN/ACK, FID=9000 ---> 678 ... (RFC5722) ... 679 #6 <------- Echo Req #2 ---------- 680 #7 ---- Echo Resp #2, FID=5001 --> 682 Clearly, the Fragment Identification value sampled by from the second 683 ICMPv6 Echo Response packet ("Echo Resp #2") implicitly indicates 684 whether the Fragment Identification in the forged SYN/ACK (see line 685 #4 in both figures) was the current Fragment Identification in use by 686 Host A. 688 As a result, the attacker could employ this technique to learn the 689 current Fragment Identification value used by host A to send packets 690 to host B, even when Host A itself has a non-vulnerable 691 implementation. 693 Appendix B. Survey of Fragment Identification selection algorithms 694 employed by popular IPv6 implementations 696 This section includes a survey of the Fragment Identification 697 selection algorithms employed in some popular operating systems. 699 The survey was produced with the SI6 Networks IPv6 toolkit 700 [SI6-IPv6]. 702 +-----------------------+-------------------------------------------+ 703 | Operating System | Algorithm | 704 +-----------------------+-------------------------------------------+ 705 | FreeBSD 9.0 | Unpredictable (Random) | 706 +-----------------------+-------------------------------------------+ 707 | Linux 3.0.0-15 | Predictable (Global Counter, Init=0, | 708 | | Incr=1) | 709 +-----------------------+-------------------------------------------+ 710 | Linux-current | Unpredictable (Per-dest Counter, | 711 | | Init=random, Incr=1) | 712 +-----------------------+-------------------------------------------+ 713 | NetBSD 5.1 | Unpredictable (Random) | 714 +-----------------------+-------------------------------------------+ 715 | OpenBSD-current | Random (SKIP32) | 716 +-----------------------+-------------------------------------------+ 717 | Solaris 10 | Predictable (Per-dst Counter, Init=0, | 718 | | Incr=1) | 719 +-----------------------+-------------------------------------------+ 720 | Windows XP SP2 | Predictable (Global Counter, Init=0, | 721 | | Incr=2) | 722 +-----------------------+-------------------------------------------+ 723 | Windows Vista (Build | Predictable (Global Counter, Init=0, | 724 | 6000) | Incr=2) | 725 +-----------------------+-------------------------------------------+ 726 | Windows 7 Home | Predictable (Global Counter, Init=0, | 727 | Premium | Incr=2) | 728 +-----------------------+-------------------------------------------+ 730 Table 1: Fragment Identification algorithms employed by different 731 OSes 733 In the text above, "predictable" should be taken as "easily 734 guessable by an off-path attacker, by sending a few probe 735 packets". 737 Author's Address 739 Fernando Gont 740 SI6 Networks / UTN-FRH 741 Evaristo Carriego 2644 742 Haedo, Provincia de Buenos Aires 1706 743 Argentina 745 Phone: +54 11 4650 8472 746 Email: fgont@si6networks.com 747 URI: http://www.si6networks.com