idnits 2.17.1 draft-ietf-6man-predictable-fragment-id-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 261: '...its of its value MUST be used for the ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3335 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: Informational ---------------------------------------------------------------------------- ** 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) == Outdated reference: A later version (-08) exists of draft-ietf-6man-deprecate-atomfrag-generation-00 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 Intended status: Informational March 9, 2015 5 Expires: September 10, 2015 7 Security Implications of Predictable Fragment Identification Values 8 draft-ietf-6man-predictable-fragment-id-04 10 Abstract 12 IPv6 specifies the Fragment Header, which is employed for the 13 fragmentation and reassembly mechanisms. The Fragment Header 14 contains an "Identification" field which, together with the IPv6 15 Source Address and the IPv6 Destination Address of a packet, 16 identifies fragments that correspond to the same original datagram, 17 such that they can be reassembled together at the receiving host. 18 The only requirement for setting the "Identification" value is that 19 it must be different than that employed for any other fragmented 20 packet sent recently with the same Source Address and Destination 21 Address. Some implementations use a simple global counter for 22 setting the Identification field, thus leading to predictable values. 23 This document analyzes the security implications of predictable 24 Identification values, and provides implementation guidance for 25 selecting the Identification field of the Fragment Header, such that 26 the aforementioned security implications are mitigated. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 10, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Security Implications of Predictable Fragment Identification 64 values . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Constraints for the selection of Fragment Identification 66 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Algorithms for Selecting Fragment Identification Values . . . 7 68 4.1. Per-destination counter (initialized to a random value) . 7 69 4.2. Randomized Identification values . . . . . . . . . . . . 8 70 4.3. Hash-based Fragment Identification selection algorithm . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 8.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Appendix A. Information leakage produced by vulnerable 78 implementations . . . . . . . . . . . . . . . . . . 13 79 Appendix B. Survey of Fragment Identification selection 80 algorithms employed by popular IPv6 implementations 15 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 IPv6 specifies the Fragment Header, which is employed for the 86 fragmentation and reassembly mechanisms. The Fragment Header 87 contains an "Identification" field which, together with the IPv6 88 Source Address and the IPv6 Destination Address of a packet, 89 identifies fragments that correspond to the same original datagram, 90 such that they can be reassembled together at the receiving host. 91 The only requirement for setting the "Identification" value is that 92 it must be different than that employed for any other fragmented 93 packet sent recently with the same Source Address and Destination 94 Address. 96 The most trivial algorithm to avoid reusing Fragment Identification 97 values too quickly is to maintain a global counter that is 98 incremented for each fragmented packet that is transmitted. However, 99 this trivial algorithm leads to predictable Identification values, 100 which can be leveraged to perform a variety of attacks. 102 Section 2 of this document analyzes the security implications of 103 predictable Identification values. Section 3 discusses constraints 104 in the possible algorithms for selecting Fragment Identification 105 values. Section 4 specifies a number of algorithms that could be 106 used for generating Identification values. Finally, Appendix B 107 contains a survey of the Fragment Identification algorithms employed 108 by popular IPv6 implementations. 110 2. Security Implications of Predictable Fragment Identification values 112 Predictable Identification values result in an information leakage 113 that can be exploited in a number of ways. Among others, they may 114 potentially be exploited to: 116 o determine the packet rate at which a given system is transmitting 117 information, 119 o perform stealth port scans to a third-party, 121 o uncover the rules of a number of firewalls, 123 o count the number of systems behind a middle-box, 125 o perform Denial of Service (DoS) attacks, or, 127 o perform data injection attacks against transport or application 128 protocols 130 The security implications introduced by predictable Fragment 131 Identification values are very similar to those of predictable 132 Identification values in IPv4. 134 [Sanfilippo1998a] originally pointed out how the IPv4 135 Identification field could be examined to determine the packet 136 rate at which a given system is transmitting information. Later, 137 [Sanfilippo1998b] described how a system with such an 138 implementation could be used to perform a stealth port scan to a 139 third (victim) host. [Sanfilippo1999] explains how to exploit 140 this implementation strategy to uncover the rules of a number of 141 firewalls. [Bellovin2002] explains how the IPv4 Identification 142 field can be exploited to count the number of systems behind a 143 NAT. [Fyodor2004] is an entire paper on most (if not all) the 144 ways to exploit the information provided by the Identification 145 field of the IPv4 header (and these results apply in a similar way 146 to IPv6). [Zalewski2003] originally envisioned the exploitation 147 of IP fragmentation/reassembly for performing data injection 148 attacks against upper-layer protocols. [Herzberg2013] explores 149 the use of IPv4/IPv6 fragmentation and predictable Identification 150 values for performing DNS cache poisoning attacks in great detail. 151 [RFC6274] covers the security implications of the IPv4 case in 152 detail. 154 One key difference between the IPv4 case and the IPv6 case is that in 155 IPv4 the Identification field is part of the fixed IPv4 header (and 156 thus usually set for all packets), while in IPv6 the Identification 157 field is present only in those packets that carry a Fragment Header. 158 As a result, successful exploitation of the IPv6 Fragment 159 Identification field depends on two different factors: 161 o vulnerable IPv6 Fragment Identification generators, and, 163 o the ability of an attacker to trigger the use of IPv6 164 fragmentation for packets sent from/to the victim node 166 As noted in the previous section, some implementations have been 167 known to use predictable Fragment Identification values. For 168 instance, Appendix B of this document shows that recent versions of a 169 number of popular IPv6 implementations have been employing 170 predictable values for the IPv6 Fragment Identification. 172 Additionally, we note that [RFC2460] states that when an ICMPv6 173 Packet Too Big error message advertising an MTU smaller than 1280 174 bytes is received, the receiving host is not required to reduce the 175 Path-MTU for the corresponding destination address, but must simply 176 include a Fragment Header in all subsequent packets sent to that 177 destination. This triggers the use of the so-called IPv6 "atomic 178 fragments" [RFC6946]: IPv6 fragments with a Fragment Offset equal to 179 0, and the "M" ("More fragments") bit clear. 180 [I-D.ietf-6man-deprecate-atomfrag-generation] aims at deprecating the 181 generation of IPv6 atomic fragments. 183 Thus, an attacker can usually cause a victim host to "fragment" its 184 outgoing packets by sending it a forged ICMPv6 'Packet Too Big' (PTB) 185 error message that advertises a Next-Hop MTU smaller than 1280 bytes. 187 There are a number of aspects that should be considered, though: 189 o All the implementations the author is aware of record the Path-MTU 190 information on a per-destination basis. Thus, an attacker can 191 only cause the victim to enable fragmentation for those packets 192 sent to the Source Address of IPv6 packet embedded in the payload 193 of the ICMPv6 PTB message. However, we note that Section 5.2 of 194 [RFC1981] notes that an implementation could maintain a single 195 system-wide PMTU value to be used for all packets sent to that 196 node. Clearly, such an implementations would exacerbate the 197 problem of any attacks based on PMTUD [RFC5927] or IPv6 198 fragmentation. 200 o If the victim node implements some of the counter-measures for 201 ICMP attacks described in RFC 5927 [RFC5927], it might be 202 difficult for an attacker to cause the victim node to use 203 fragmentation for its outgoing packets. However, many current 204 implementations fail to enforce these validation checks. For 205 example, Linux 2.6.38-8 does not even require received ICMPv6 206 error messages to correspond to an ongoing communication instance. 208 Implementations that employ predictable Identification values and 209 also fail to enforce validation checks on ICMPv6 error messages 210 become vulnerable to the same type of attacks that can be exploited 211 with IPv4 fragmentation, discussed earlier in this section. 213 One possible way in which predictable Identification values could be 214 leveraged for performing a Denial of Service (DoS) attack is as 215 follows: Let us assume that Host A is communicating with Host B, and 216 that an attacker wants to DoS attack such communication. The 217 attacker would learn the the Identification value currently in use by 218 Host A, possibly by sending any packet that would elicit a fragmented 219 response (e.g., an ICPMv6 echo request with a large payload). The 220 attacker would then send a forged ICMPv6 Packet Too Big error message 221 to Host A (with the IPv6 Destination Address of the embedded IPv6 222 packet set to the IPv6 address of a Host B), such that any subsequent 223 packets sent by Host A to Host B include a Fragment Header. Finally, 224 the attacker would send forged IPv6 fragments to Host B, with their 225 IPv6 Source Address set to that of Host A, and Identification values 226 that would result in collisions with the Identification values 227 employed for the legitimate traffic sent by Host A to Host B. If 228 Host B discards fragments that result in collisions of Identification 229 values (e.g., such fragments overlap, and the host implements 230 [RFC5722]), the attacker could simply trash the Identification space 231 by sending multiple forged fragments with different Identification 232 values, such that any subsequent packets from Host A to Host B are 233 discarded at Host B as a result of the malicious fragments sent by 234 the attacker. 236 NOTES: 238 For example, Linux 2.6.38-10 is vulnerable to the aforementioned 239 issue. 241 [RFC6946] describes an improved processing of these packets that 242 would eliminate this specific attack vector, at least in the case 243 of TCP connections that employ the Path-MTU Discovery mechanism. 245 The previous attack scenario is simply included to illustrate the 246 problem of employing predictable fragment Identification values. We 247 note that regardless of the attacker's ability to cause a victim host 248 to employ fragmentation when communicating with third-parties, use of 249 predictable Identification values makes communication flows that 250 employ fragmentation vulnerable to any fragmentation-based attacks. 252 3. Constraints for the selection of Fragment Identification Values 254 The "Identification" field of the Fragmentation Header is 32-bits 255 long. However, when translators [RFC6145] are employed, the 256 "effective" length of the IPv6 Fragment Identification field is 16 257 bits. 259 NOTE: [RFC6145] notes that, when translating in the IPv6-to-IPv4 260 direction, "if there is a Fragment Header in the IPv6 packet, the 261 last 16 bits of its value MUST be used for the IPv4 identification 262 value". This means that the high-order 16 bits are effectively 263 ignored. 265 As a result, at least during the IPv6/IPv4 transition/co-existence 266 phase, it is probably safer to assume that only the low-order 16 bits 267 of the IPv6 Fragment Identification are of use to the destination 268 system. 270 Regarding the selection of Fragment Identification values, the only 271 requirement specified in [RFC2460] is that the Fragment 272 Identification must be different than that of any other fragmented 273 packet sent recently with the same Source Address and Destination 274 Address. Failure to comply with this requirement could lead to the 275 interoperability problems discussed in [RFC4963]. 277 From a security standpoint, unpredictable Identification values are 278 desirable. However, this is somewhat at odds with the "re-use" 279 requirements specified in [RFC2460], that specifies that an 280 Identification value must be different than that of any other 281 fragment sent recently. 283 Finally, since Fragment Identification values need to be selected for 284 each outgoing datagram that requires fragmentation, the performance 285 impact should be considered when choosing an algorithm for the 286 selection of Fragment Identification values. 288 4. Algorithms for Selecting Fragment Identification Values 290 This section specifies a number of algorithms that may be used for 291 selecting Fragment Identification values. 293 4.1. Per-destination counter (initialized to a random value) 295 1. Whenever a packet must be sent with a Fragment Header, the 296 sending host should look-up in the Destinations Cache an entry 297 corresponding to the Destination Address of the packet. 299 2. If such an entry exists, it contains the last Fragment 300 Identification value used for that Destination Address. 301 Therefore, such value should be incremented by 1, and used for 302 setting the Fragment Identification value of the outgoing packet. 303 Additionally, the updated value should be recorded in the 304 corresponding entry of the Destination Cache [RFC4861]. 306 3. If such an entry does not exist, it should be created, and the 307 "Identification" value for that destination should be initialized 308 with a random value (e.g., with a pseudorandom number generator), 309 and used for setting the Identification field of the Fragment 310 Header of the outgoing packet. 312 The advantages of this algorithm are: 314 o It is simple to implement, with the only complexity residing in 315 the Pseudo-Random Number Generator (PRNG) used to initialize the 316 "Identification" value contained in each entry of the Destinations 317 Cache. 319 o The "Identification" re-use frequency will typically be lower than 320 that achieved by a global counter (when sending traffic to 321 multiple destinations), since this algorithm uses per-destination 322 counters (rather than a single system-wide counter). 324 o It has good performance properties (once the corresponding entry 325 in the Destinations Cache has been created, each subsequent 326 "Identification" value simply involves the increment of a 327 counter). 329 The possible drawbacks of this algorithm are: 331 o If as a result of resource management an entry of the Destinations 332 Cache must be removed, the last Fragment Identification value used 333 for that Destination will be lost. Thus, subsequent traffic to 334 that destination would cause that entry to be re-created and re- 335 initialized to random value, thus possibly leading to Fragment 336 Identification "collisions". 338 o Since the Fragment Identification values are predictable by the 339 destination host, a vulnerable host might possibly leak to third- 340 parties the Fragment Identification values used by other hosts to 341 send traffic to it (i.e., Host B could leak to Host C the Fragment 342 Identification values that Host A is using to send packets to Host 343 B). Appendix A describes one possible scenario for such leakage 344 in detail. 346 4.2. Randomized Identification values 348 Clearly, use of a Pseudo-Random Number Generator for selecting the 349 Fragment Identification would be desirable from a security 350 standpoint. With such a scheme, the Fragment Identification of each 351 fragmented datagram would be selected as: 353 Identification = random() 355 where "random()" is the PRNG. 357 The specific properties of such scheme would clearly depend on the 358 specific PRNG algorithm used. For example, some PRNGs may result in 359 higher Fragment Identification reuse frequencies than others, in the 360 same way that some PRNGs may be more expensive (in terms of 361 processing requirements and/or implementation complexity) than 362 others. 364 Discussion of the properties of possible PRNGs is considered out of 365 the scope of this document. However, we do note that some PRNGs 366 employed in the past by some implementations have been found to be 367 predictable [Klein2007]. Please see [RFC4086] for randomness 368 requirements for security. 370 4.3. Hash-based Fragment Identification selection algorithm 372 Another alternative is to implement a hash-based algorithm similar to 373 that specified in [RFC6056] for the selection of transport port 374 numbers. With such a scheme, the Fragment Identification value of 375 each fragment datagram would be selected with the expression: 377 Identification = F(Src IP, Dst IP, secret1) + 378 counter[G(src IP, Dst Pref, secret2)] 380 where: 382 Identification: 383 Identification value to be used for the fragmented datagram 385 F(): 386 Hash function 388 Src IP: 389 IPv6 Source Address of the datagram to be fragmented 391 Dst IP: 392 IPv6 Destination Address of the datagram to be fragmented 394 secret1: 395 Secret data unknown to the attacker 397 counter[]: 398 System-wide array of 32-bit counters (e.g. with 8K elements or 399 more) 401 G(): 402 Hash function. May or may not be the same hash function as that 403 used for F() 405 Dst Pref: 406 IPv6 "Destination Prefix" of datagram to be fragmented (can be 407 assumed to be the first eight bytes of the Destination Address of 408 such packet). Note: the "Destination Prefix" (rather than 409 Destination Address) is used, such that the ability of an attacker 410 of searching the "increments" space by using multiple addresses of 411 the same subnet is reduced. 413 secret2: 414 Secret data unknown to the attacker 416 NOTE: counter[G(src IP, Dst Pref, secret2)] should be incremented by 417 one each time an Identification value is selected. 419 The advantages of this algorithm are: 421 o The "Identification" re-use frequency will typically be lower than 422 that achieved by a global counter (when sending traffic to 423 multiple destinations), since this algorithm uses multiple system- 424 wide counters (rather than a single system-wide counter). The 425 extent to which the re-use frequency will be lower will depend on 426 the number of elements in counter[], and the number of other 427 active flows that result in the same value of G() (and hence cause 428 the same counter to be incremented for each fragmented datagram 429 that is sent). 431 o It is possible to implement the algorithm such that good 432 performance is achieved. For example, the result of F() could be 433 stored in the Destinations Cache (such that it need not be 434 recomputed for each packet that must be sent) along with the 435 computed "index"/argument for counter[]. 437 NOTE: If this implementation approach is followed, and an entry 438 of the Destinations Cache must be removed as a result of 439 resource management, the last Fragment Identification value 440 used for that Destination will *not* be lost. This is an 441 improvement over the algorithm specified in Section 4.1. 443 The possible drawbacks of this algorithm are: 445 o Since the Fragment Identification values are predictable by the 446 destination host, a vulnerable host could possibly leak to third- 447 parties the Fragment Identification values used by other hosts to 448 send traffic to it (i.e., Host B could leak to Host C the Fragment 449 Identification values that Host A is using to send packets to Host 450 B). Appendix A describes a possible scenario in which that 451 information leakage could take place. We note, however, that this 452 algorithm makes the aforementioned attack less reliable for the 453 attacker, since each counter could be possibly shared by multiple 454 traffic flows (i.e., packets destined to other destinations might 455 cause the same counter to be incremented). 457 This algorithm might be preferable (over the one specified in 458 Section 4.1) in those scenarios in which a node is expected to 459 communicate with a large number of destinations, and thus it is 460 desirable to limit the amount of information to be maintained in 461 memory. 463 NOTE: In such scenarios, if the algorithm specified in Section 4.1 464 were implemented, entries from the Destinations Cache might need 465 to be pruned frequently, thus increasing the risk of fragment 466 Identification collisions. 468 5. IANA Considerations 470 There are no IANA registries within this document. The RFC-Editor 471 can remove this section before publication of this document as an 472 RFC. 474 6. Security Considerations 476 This document discusses the security implications of predictable 477 Fragment Identification values, and provides implementation guidance 478 such that the aforementioned security implications can be mitigated. 480 A number of possible algorithms are described, to provide some 481 implementation alternatives to implementers. We note that the 482 selection of such an algorithm usually implies a number of trade-offs 483 (security, performance, implementation complexity, interoperability 484 properties, etc.). 486 7. Acknowledgements 488 The author would like to thank Ivan Arce for proposing the attack 489 scenario described in Appendix A. 491 The author would like to thank Ivan Arce, Ron Bonica, Tassos 492 Chatzithomaoglou, Brian Haberman, Bob Hinden, Tatuya Jinmei, Merike 493 Kaeo, Will Liu, Juan Antonio Matos, Simon Perreault, Hosnieh Rafiee, 494 Mark Smith, and Dave Thaler for providing valuable comments on 495 earlier versions of this document. 497 This document is based on work performed by Fernando Gont on behalf 498 of the UK Centre for the Protection of National Infrastructure 499 (CPNI). 501 8. References 503 8.1. Normative References 505 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 506 for IP version 6", RFC 1981, August 1996. 508 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 509 (IPv6) Specification", RFC 2460, December 1998. 511 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 512 Requirements for Security", BCP 106, RFC 4086, June 2005. 514 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 515 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 516 September 2007. 518 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 519 RFC 5722, December 2009. 521 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 522 Protocol Port Randomization", BCP 156, RFC 6056, January 523 2011. 525 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 526 Algorithm", RFC 6145, April 2011. 528 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 529 6946, May 2013. 531 8.2. Informative References 533 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 534 Errors at High Data Rates", RFC 4963, July 2007. 536 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 538 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 539 Version 4", RFC 6274, July 2011. 541 [I-D.ietf-6man-deprecate-atomfrag-generation] 542 Gont, F., Will, W., and t. tore, "Deprecating the 543 Generation of IPv6 Atomic Fragments", draft-ietf-6man- 544 deprecate-atomfrag-generation-00 (work in progress), 545 November 2014. 547 [Bellovin2002] 548 Bellovin, S., "A Technique for Counting NATted Hosts", 549 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 551 [Fyodor2004] 552 Fyodor, , "Idle scanning and related IP ID games", 2004, 553 . 555 [Herzberg2013] 556 Herzberg, A. and H. Shulman, "Fragmentation Considered 557 Poisonous", Technical Report 13-03, March 2013, 558 . 560 [Klein2007] 561 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 562 Predictable IP ID Vulnerability", 2007, 563 . 566 [Sanfilippo1998a] 567 Sanfilippo, S., "about the ip header id", Post to Bugtraq 568 mailing-list, Mon Dec 14 1998, 569 . 571 [Sanfilippo1998b] 572 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 573 1998, . 575 [Sanfilippo1999] 576 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 577 list, 1999, 578 . 580 [SI6-IPv6] 581 "SI6 Networks' IPv6 toolkit", 582 . 584 [Zalewski2003] 585 Zalewski, M., "A new TCP/IP blind data injection 586 technique?", Post to Bugtraq mailing-list, Thu, 11 Dec 587 2003 00:28:28 +0100 (CET), 2003, 588 . 590 Appendix A. Information leakage produced by vulnerable implementations 592 Section 2 provides a number of references describing a number of ways 593 in which a vulnerable implementation may reveal the Fragment 594 Identification values to be used in subsequent packets, thus opening 595 the door to a number of attacks. In all of those scenarios, a 596 vulnerable implementation leaks/reveals its own Identification 597 number. 599 This section presents a attack scenario, in which a vulnerable 600 implementation leaks/reveals the Identification number of a non- 601 vulnerable implementation. That is, a vulnerable implementation 602 (Host A) leaks the current Fragment Identification value in use by a 603 third-party host (Host B) to send fragmented datagrams from Host B to 604 Host A. 606 For the most part, this section is included to illustrate how a 607 vulnerable implementation might be leveraged to leak-out the 608 Fragment Identification value of an otherwise non-vulnerable 609 implementation. 611 The following scenarios assume: 613 Host A: 614 Is an IPv6 host that implements the the algorithm specified in 615 Section 4.1, implements [RFC5722], but does not implement 616 [RFC6946]. 618 Host B: 619 Victim node. Selects the Fragment Identification values from a 620 global counter. 622 Host C: 624 Attacker. Can forge the IPv6 Source Address of his packets at 625 will. 627 In the following scenarios, large ICMPv6 Echo Request packets are 628 employed to "sample" the Fragment Identification value of a host. We 629 note that while the figures show only one packet for the ICMPv6 Echo 630 Request and the ICMPv6 Echo Response, each of those packets will 631 typically comprise two fragments, such that the corresponding 632 unfragmented datagram is larger than the MTU of the networks to which 633 Host B and Host C are attached. 635 In lines #1-#2 (and lines #8-#9), the attacker samples the current 636 Fragment Identification value. In line #3, the attacker sends a 637 forged TCP SYN segment to Host A. If corresponding TCP port is 638 closed, and the attacker fails when trying to produce a collision of 639 Fragment Identifications (see line #4), the following packet exchange 640 might take place: 642 A B C 644 #1 <------ Echo Req #1 ----------- 645 #2 --- Echo Resp #1, FID=5000 ---> 646 #3 <------------------- SYN #1, src= B ----------------------- 647 #4 <--- SYN/ACK, FID=42 src = A--- 648 #5 ---- SYN/ACK, FID=9000 ---> 649 #6 <----- RST, FID= 5001 ----- 650 #7 <----- RST, FID= 5002 ----- 651 #8 <-------- Echo Req #2 --------- 652 #9 --- Echo Resp #2, FID=5003 ---> 654 The two RST segments are elicited by the SYN/ACK segment from line 655 #4, and the (illegitimately elicited by the SYN in line #3) SYN/ACK 656 segment from line #5. On the other hand, if the attacker succeeds to 657 produce a collision of Fragment Identification values, the following 658 packet exchange could take place: 660 A B C 662 #1 <------- Echo Req #1 ---------- 663 #2 --- Echo Resp #1, FID=5000 ---> 664 #3 <------------------- SYN #1, src= B ----------------------- 665 #4 <-- SYN/ACK, FID=9000 src=A --- 666 #5 ---- SYN/ACK, FID=9000 ---> 667 ... (RFC5722) ... 668 #6 <------- Echo Req #2 ---------- 669 #7 ---- Echo Resp #2, FID=5001 --> 670 Clearly, the Fragment Identification value sampled from the second 671 ICMPv6 Echo Response packet ("Echo Resp #2") implicitly indicates 672 whether the Fragment Identification in the forged SYN/ACK (see line 673 #4 in both figures) was the current Fragment Identification in use by 674 Host A. 676 As a result, the attacker could employ this technique to learn the 677 current Fragment Identification value used by host A to send packets 678 to host B, even when Host A itself has a non-vulnerable 679 implementation. 681 Appendix B. Survey of Fragment Identification selection algorithms 682 employed by popular IPv6 implementations 684 This section includes a survey of the Fragment Identification 685 selection algorithms employed in some popular operating systems. 687 The survey was produced with the SI6 Networks IPv6 toolkit 688 [SI6-IPv6]. 690 +------------------------------+------------------------------------+ 691 | Operating System | Algorithm | 692 +------------------------------+------------------------------------+ 693 | Cisco IOS 15.3 | Predictable (Global Counter, | 694 | | Init=0, Incr=1) | 695 +------------------------------+------------------------------------+ 696 | FreeBSD 9.0 | Unpredictable (Random) | 697 +------------------------------+------------------------------------+ 698 | Linux 3.0.0-15 | Predictable (Global Counter, | 699 | | Init=0, Incr=1) | 700 +------------------------------+------------------------------------+ 701 | Linux-current | Unpredictable (Per-dest Counter, | 702 | | Init=random, Incr=1) | 703 +------------------------------+------------------------------------+ 704 | NetBSD 5.1 | Unpredictable (Random) | 705 +------------------------------+------------------------------------+ 706 | OpenBSD-current | Random (SKIP32) | 707 +------------------------------+------------------------------------+ 708 | Solaris 10 | Predictable (Per-dst Counter, | 709 | | Init=0, Incr=1) | 710 +------------------------------+------------------------------------+ 711 | Windows XP SP2 | Predictable (Global Counter, | 712 | | Init=0, Incr=2) | 713 +------------------------------+------------------------------------+ 714 | Windows XP Professional | Predictable (Global Counter, | 715 | 32bit, SP3 | Init=0, Incr=2) | 716 +------------------------------+------------------------------------+ 717 | Windows Vista (Build 6000) | Predictable (Global Counter, | 718 | | Init=0, Incr=2) | 719 +------------------------------+------------------------------------+ 720 | Windows Vista Business | Predictable (Global Counter, | 721 | 64bit, SP1 | Init=0, Incr=2) | 722 +------------------------------+------------------------------------+ 723 | Windows 7 Home Premium | Predictable (Global Counter, | 724 | | Init=0, Incr=2) | 725 +------------------------------+------------------------------------+ 726 | Windows Server 2003 R2 | Predictable (Global Counter, | 727 | Standard 64bit, SP2 | Init=0, Incr=2) | 728 +------------------------------+------------------------------------+ 729 | Windows Server 2008 Standard | Predictable (Global Counter, | 730 | 32bit, SP1 | Init=0, Incr=2) | 731 +------------------------------+------------------------------------+ 732 | Windows Server 2008 R2 | Predictable (Global Counter, | 733 | Standard 64bit, SP1 | Init=0, Incr=2) | 734 +------------------------------+------------------------------------+ 735 | Windows Server 2012 Standard | Predictable (Global Counter, | 736 | 64bit | Init=0, Incr=2) | 737 +------------------------------+------------------------------------+ 738 | Windows 7 Home Premium | Predictable (Global Counter, | 739 | 32bit, SP1 | Init=0, Incr=2) | 740 +------------------------------+------------------------------------+ 741 | Windows 7 Ultimate 32bit, | Predictable (Global Counter, | 742 | SP1 | Init=0, Incr=2) | 743 +------------------------------+------------------------------------+ 744 | Windows 8 Enterprise 32 bit | Predictable (Global Counter, | 745 | | Init=0, Incr=2) | 746 +------------------------------+------------------------------------+ 748 Table 1: Fragment Identification algorithms employed by different 749 OSes 751 In the text above, "predictable" should be taken as "easily 752 guessable by an off-path attacker, by sending a few probe 753 packets". 755 Author's Address 757 Fernando Gont 758 SI6 Networks / UTN-FRH 759 Evaristo Carriego 2644 760 Haedo, Provincia de Buenos Aires 1706 761 Argentina 763 Phone: +54 11 4650 8472 764 Email: fgont@si6networks.com 765 URI: http://www.si6networks.com