idnits 2.17.1 draft-gont-6man-predictable-fragment-id-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 (January 9, 2013) is 4124 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: Proposed Standard ---------------------------------------------------------------------------- (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) == Outdated reference: A later version (-04) exists of draft-ietf-6man-ipv6-atomic-fragments-03 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 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) January 9, 2013 5 Intended status: Standards Track 6 Expires: July 13, 2013 8 Security Implications of Predictable Fragment Identification Values 9 draft-gont-6man-predictable-fragment-id-03 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 the 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 of any other fragmented packet sent 21 recently with the same Source Address and Destination Address. Some 22 implementations simply use a global counter for setting the Fragment 23 Identification field, thus leading to predictable values. This 24 document analyzes the security implications of predictable 25 Identification values, and updates RFC 2460 specifying additional 26 requirements for setting the Fragment Identification, such that the 27 aforementioned security implications are mitigated. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. This document may not be modified, 33 and derivative works of it may not be created, and it may not be 34 published except as an Internet-Draft. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 13, 2013. 48 Copyright Notice 49 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Security Implications of Predictable Fragment 66 Identification values . . . . . . . . . . . . . . . . . . . . 4 67 3. Updating RFC 2460 . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Constraints for the selection of Fragment Identification 69 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Algorithms for Selecting Fragment Identification Values . . . 10 71 5.1. Per-destination counter (initialized to a random value) . 10 72 5.2. Randomized Identification values . . . . . . . . . . . . . 11 73 5.3. Hash-based Fragment Identification selection algorithm . . 11 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 80 Appendix A. Information leakage produced by vulnerable 81 implementations . . . . . . . . . . . . . . . . . . . 19 82 Appendix B. Survey of Fragment Identification selection 83 algorithms employed by popular IPv6 84 implementations . . . . . . . . . . . . . . . . . . . 21 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 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 the packet, 93 identifies fragments that correspond to the same original datagram, 94 such that they can be reassembled together at the receiving host. 95 The only requirement for setting the "Identification" value is that 96 it must be different than that of any other fragmented packet sent 97 recently with the same Source Address and Destination Address. 99 The most trivial algorithm to avoid reusing Fragment Identification 100 values too quickly is to maintain a global counter that is 101 incremented for each fragmented packet that is sent. However, this 102 trivial algorithm leads to predictable Identification values, which 103 can be leveraged for performing a variety of attacks. 105 Section 2 of this document analyzes the security implications of 106 predictable Identification values. Section 3 updates RFC 2460 by 107 adding the requirement that Identification values not be predictable 108 by an off-path attacker. Section 4 discusses constraints in the 109 possible algorithms for selecting Fragment Identification values. 110 Section 5 specifies a number of algorithms that could be used for 111 generating Identification values. Finally, Appendix B contains a 112 survey of the Fragment Identification algorithms employed by popular 113 IPv6 implementations. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Security Implications of Predictable Fragment Identification values 121 Predictable Identification values result in an information leakage 122 that can be exploited in a number of ways. Among others, they may 123 potentially be exploited to: 125 o determine the packet rate at which a given system is transmitting 126 information, 128 o perform stealth port scans to a third-party, 130 o uncover the rules of a number of firewalls, 132 o count the number of systems behind a middle-box, or, 134 o perform a Denial of Service (DoS) attack 136 [CPNI-IPv6] contains a detailed analysis of possible vulnerabilities 137 introduced by predictable Fragment Identification values. In 138 summary, their security implications are very similar to those of 139 predictable Identification values in IPv4. 141 [Sanfilippo1998a] originally pointed out how the IPv4 142 Identification field could be examined to determine the packet 143 rate at which a given system is transmitting information. Later, 144 [Sanfilippo1998b] described how a system with such an 145 implementation could be used to perform a stealth port scan to a 146 third (victim) host. [Sanfilippo1999] explained how to exploit 147 this implementation strategy to uncover the rules of a number of 148 firewalls. [Bellovin2002] explains how the IPv4 Identification 149 field can be exploited to count the number of systems behind a 150 NAT. [Fyodor2004] is an entire paper on most (if not all) the 151 ways to exploit the information provided by the Identification 152 field of the IPv4 header (and these results apply in a similar way 153 to IPv6). [RFC6274] covers the security implications of IPv4 in 154 detail. 156 One key difference between the IPv4 case and the IPv6 case is that in 157 IPv4 the Identification field is part of the fixed IPv4 header (and 158 thus usually set for all packets), while in IPv6 the Identification 159 field is set only in those packets that employ a Fragment Header. As 160 a result, successful exploitation of the Identification field against 161 communication instances with arbitrary destinations depends on two 162 different factors: 164 o IPv6 implementations using predictable Identification values, and, 165 o the ability of the attacker to cause the victim host to fragment 166 packets destined to other nodes 168 As noted in the previous section, some implementations are known to 169 use predictable identification values. 171 For example, Linux 2.6.38-8 sets the Identification field 172 according to a global counter that is incremented by one for each 173 datagram that is sent with a fragment header (either a single 174 fragment or as multiple fragments). 176 Finally, we note that an attacker could cause a victim host to 177 fragment its outgoing packets by sending it a forged ICMPv6 'Packet 178 Too Big' error message advertising a Next-Hop MTU smaller than 1280 179 bytes. 181 RFC 1981 [RFC1981] states that when an ICMPv6 Packet Too Big error 182 message with an MTU smaller than 1280 bytes is received, the 183 receiving host is not required to reduce the Path-MTU for the 184 corresponding destination address, but must simply include a 185 Fragment Header in all subsequent packets sent to that 186 destination. In order to make sure that the forged ICMPv6 Packet 187 Too Big error message triggers fragmentation at the victim host, 188 the attacker could set the MTU field of the error message to a 189 value smaller than 1280 bytes. Since the minimum IPv6 MTU is 1280 190 bytes, such value would always be smaller than the Path-MTU in use 191 for that destination. 193 There are a few issues that should be considered, though: 195 o In all the implementations the author is aware of, an attacker can 196 only cause the victim to enable fragmentation on a per-destination 197 basis. That is, the victim will use fragmentation only for those 198 packets sent to the Source Address of IPv6 packet embedded in the 199 payload of the ICMPv6 Packet Too Big error message. 201 Section 5.2 of [RFC1981] notes that an implementation could 202 maintain a single system-wide PMTU value to be used for all 203 packets originating from that nodes. Clearly, such an 204 implementations would exacerbate the problem of any attacks 205 based on PMTUD [RFC5927] or IPv6 fragmentation. 207 o If the victim node implements some of the counter-measures for 208 ICMP attacks described in RFC 5927 [RFC5927], it might be 209 difficult for an attacker to cause the victim node to use 210 fragmentation for its outgoing packets. 212 Some implementations do not incorporate countermeasures for 213 attacks based on ICMPv6 error messages. For example, Linux 214 2.6.38-8 does not even require received ICMPv6 error messages 215 to correspond to ongoing communication instances. 217 Implementations that employ predictable Identification values and 218 also fail to include countermeasures against attacks based on ICMPv6 219 error messages will be vulnerable to attacks similar to those based 220 on the IPv4 Identification field for IPv4 networks, such as the 221 stealth port-scanning technique described in [Sanfilippo1998b]. 223 One possible way in which predictable Identification values could be 224 leveraged for performing a Denial of Service (DoS) attack is as 225 follows: once the Identification value currently in use at the victim 226 host has been learned, the attacker would send a forged ICMPv6 Packet 227 Too Big error message to the victim host, with the IPv6 Destination 228 Address of the embedded IPv6 packet set to the IPv6 address of a 229 third-party host with which the victim is communicating. This ICMPv6 230 Packet Too Big error message would cause any packets sent from the 231 victim to the third-party host to include a Fragment Header. The 232 attacker would then send forged IPv6 fragments to the third-party 233 host, with their IPv6 Source Address set to that of the victim host, 234 and with the Identification field of the forged fragments set to 235 values that would result in collisions at the third-party host. If 236 the third-party host discards fragments that result in collisions of 237 Identification values, the attacker could simply trash the 238 Identification space by sending multiple forged fragments with 239 different Identification values, such that any subsequent packets 240 from the victim host are discarded at the third-party host as a 241 result of the malicious fragments sent by the attacker. 243 For example, Linux 2.6.38-10 is vulnerable to the aforementioned 244 issue. 246 [I-D.ietf-6man-ipv6-atomic-fragments] describes an improved 247 processing of these packets that would eliminate this specific 248 attack vector, at least in the case of TCP connections that employ 249 the Path-MTU Discovery mechanism. 251 The aforementioned attack scenario is simply included to illustrate 252 the problem of employing predictable fragment Identification values, 253 rather than to indicate a specific attack vector that needs to be 254 mitigated. 256 We note that regardless of the attacker's ability to cause a victim 257 host to employ fragmentation when communicating with third-parties, 258 use of predictable Identification values makes communication flows 259 that employ fragmentation vulnerable to any fragmentation-based 260 attacks. 262 3. Updating RFC 2460 264 Hereby we update RFC 2460 [RFC2460] as follows: 266 The Identification value of the Fragment Header MUST NOT be 267 predictable by an off-path attacker. 269 4. Constraints for the selection of Fragment Identification Values 271 the "Identification" field of the Fragmentation Header is 32-bits 272 long. However, when translators [RFC6145] are employed, the 273 "effective" length of the IPv6 Fragment Identification field is 16 274 bits. 276 [RFC6145] notes that, when translating in the IPv6-to-IPv4 277 direction, "if there is a Fragment Header in the IPv6 packet, the 278 last 16 bits of its value MUST be used for the IPv4 identification 279 value". This means that the high-order 16 bits are effectively 280 ignored. 282 As a result, at least during the IPv6/IPv4 transition/co-existence 283 phase, it is probably safer to assume that only the last 16 bits of 284 the IPv6 Fragment Identification may be used in some cases. 286 Regarding the selection of Fragment Identification values, the only 287 requirement specified in [RFC2460] is that the Fragment 288 Identification must be different than that of any other fragmented 289 packet sent recently with the same Source Address and Destination 290 Address. 292 Failure to comply with that requirement might 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 5. 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 5.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 intended Destination Address. 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 is obviously lost. Thus, if subsequent 350 traffic to that destination causes the aforementioned entry to be 351 re-created, the Fragment Identification value will be randomized, 352 thus possibly leading to Fragment Identification "collisions". 354 o Since the Fragment Identification values are predictable by the 355 destination host, a vulnerable host might possible 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). 361 Appendix A describes a scenario in which that information 362 leakage could take place. 364 5.2. Randomized Identification values 366 Clearly, use of a Pseudo-Random Number Generator for selecting the 367 Fragment Identification could be desirable from a security 368 standpoint. With such a scheme, the Fragment Identification of each 369 fragmented datagram would be selected as: 371 Identification = random() 373 where "random()" is the PRNG. 375 The specific properties of such scheme would clearly depend on the 376 specific PRNG algorithm used. For example, some PRNGs may result in 377 higher Fragment Identification reuse frequencies than others, in the 378 same way as some PRNGs may be more expensive (in terms of processing 379 requirements and/or implementation complexity) than others. 381 Discussion of the properties of possible PRNGs is considered out of 382 the scope of this document. However, we do note that some PRNGs 383 employed in the past by some implementations have been found to be 384 predictable [Klein2007]. Please see [RFC4086] for randomness 385 requirements for security. 387 5.3. Hash-based Fragment Identification selection algorithm 389 Another alternative is to implement a hash-based algorithm similar to 390 that specified in for the selection of transport port numbers. With 391 such a scheme, the Fragment Identification value of each fragment 392 datagram would be selected with the expression: 394 Identification = F(Src IP, Dst IP, secret1) + 395 counter[G(src IP, Dst Pref, secret2)] 397 where: 399 Identification: 400 Identification value to be used for the fragmented datagram 402 F(): 403 Hash function 405 Src IP: 406 IPv6 Source Address of the datagram to be fragmented 408 Dst IP: 409 IPv6 Destination Address of the datagram to be fragmented 411 secret1: 412 Secret data unknown to the attacker 414 counter[]: 415 System-wide array of 32-bit counters (e.g. with 8K elements or 416 more) 418 G(): 419 Hash function. May or may not be the same hash function as that 420 used for F() 422 Dst Pref: 423 IPv6 "Destination Prefix" of datagram to be fragmented (can be 424 assumed to be the first eight bytes of the Destination Address of 425 such packet). Note: the "Destination Prefix" (rather than 426 Destination Address) is used, such that the ability of an attacker 427 of searching the "increments" space by using multiple addresses of 428 the same subnet is reduced. 430 secret1: 431 Secret data unknown to the attacker 433 Note: counter[G(src IP, Dst Pref, secret2)] should be incremented by 434 one each time an Identification value is selected. 436 The advantages of this algorithm are: 438 o The "Identification" re-use frequency will typically be lower than 439 that achieved by a global counter (when sending traffic to 440 multiple destinations), since this algorithm uses multiple system- 441 wide counters (rather than a single system-wide counter). The 442 extent to which the re-use frequency will be lower will depend on 443 the number of elements in counter[], and the number of other 444 active flows that result in the same value of G() (and hence cause 445 the same counter to be incremented for each fragmented datagram 446 that is sent). 448 o It is possible to implement the algorithm such that good 449 performance is achieved. For example, the result of F() could be 450 stored in the Destinations Cache (such that it need not be 451 recomputed for each packet that must be sent) along with computed 452 *index* for counter[]. 454 It should be noted that if this implementation approach is 455 followed, and an entry of the Destinations Cache must be 456 removed as a result of resource management, the last Fragment 457 Identification value used for that Destination will *not* lost. 458 This is an improvement over the algorithm specified in 459 Section 5.1. 461 The possible drawbacks of this algorithm are: 463 o Since the Fragment Identification values are predictable by the 464 destination host, a vulnerable host could possibly leak to third- 465 parties the Fragment Identification values used by other hosts to 466 send traffic to it (i.e., Host B could leak to Host C the Fragment 467 Identification values that Host A is using to send packets to Host 468 B). 470 Appendix A describes a scenario in which that information 471 leakage could take place. We note, however, that this 472 algorithm makes the aforementioned attack less reliable for the 473 attacker, since each counter could be possibly shared by 474 multiple traffic flows (i.e., packets destined to other 475 destinations might cause the counter to be incremented). 477 This algorithm might be preferable (over the one specified in 478 Section 5.1) in those scenarios in which a node is expected to 479 communicate with a large number of destinations, and thus it is 480 desirable to limit the amount of information to be maintained in 481 memory. 483 In such scenarios, if the algorithm specified in Section 5.1 were 484 implemented, entries from the Destinations Cache might need to be 485 pruned frequently, thus increasing the risk of fragment 486 Identification collisions. 488 6. IANA Considerations 490 There are no IANA registries within this document. The RFC-Editor 491 can remove this section before publication of this document as an 492 RFC. 494 7. Security Considerations 496 This document discusses the security implications of predictable 497 Fragment Identification values, and updates RFC 2460 such that 498 Fragment Identification values are required to be unpredictable by 499 off-path attackers, hence mitigating the aforementioned security 500 implications. 502 A number of possible algorithms are specified, to provide some 503 implementation alternatives to implementers. However, the selection 504 of an specific algorithm that complies with Section 3 is left to 505 implementers. We note that the selection of such an algorithm 506 usually implies a number of trade-offs (security, performance, 507 implementation complexity, interoperability properties, etc.). 509 8. Acknowledgements 511 The author would like to thank Ivan Arce for proposing the attack 512 scenario described in Appendix A, and for providing valuable comments 513 on earlier versions of this document. 515 The author would like to thank Dave Thaler for providing valuable 516 comments on earlier versions of this document. 518 This document is based on the technical report "Security Assessment 519 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 520 Fernando Gont on behalf of the UK Centre for the Protection of 521 National Infrastructure (CPNI). 523 Fernando Gont would like to thank the UK CPNI 524 (http://www.cpni.gov.uk) for their continued support. 526 9. References 528 9.1. Normative References 530 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 531 for IP version 6", RFC 1981, August 1996. 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 537 (IPv6) Specification", RFC 2460, December 1998. 539 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 540 Requirements for Security", BCP 106, RFC 4086, June 2005. 542 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 543 RFC 5722, December 2009. 545 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 546 Algorithm", RFC 6145, April 2011. 548 9.2. Informative References 550 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 551 Errors at High Data Rates", RFC 4963, July 2007. 553 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 555 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 556 Version 4", RFC 6274, July 2011. 558 [I-D.ietf-6man-ipv6-atomic-fragments] 559 Gont, F., "Processing of IPv6 "atomic" fragments", 560 draft-ietf-6man-ipv6-atomic-fragments-03 (work in 561 progress), December 2012. 563 [Bellovin2002] 564 Bellovin, S., "A Technique for Counting NATted Hosts", 565 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 567 [CPNI-IPv6] 568 Gont, F., "Security Assessment of the Internet Protocol 569 version 6 (IPv6)", UK Centre for the Protection of 570 National Infrastructure, (available on request). 572 [Fyodor2004] 573 Fyodor, "Idle scanning and related IP ID games", 2004, 574 . 576 [Klein2007] 577 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 578 Predictable IP ID Vulnerability", 2007, . 583 [Sanfilippo1998a] 584 Sanfilippo, S., "about the ip header id", Post to Bugtraq 585 mailing-list, Mon Dec 14 1998, 586 . 588 [Sanfilippo1998b] 589 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 590 1998, . 592 [Sanfilippo1999] 593 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 594 list, 1999, 595 . 597 [SI6-IPv6] 598 "SI6 Networks' IPv6 toolkit", 599 . 601 Appendix A. Information leakage produced by vulnerable implementations 603 Section 2 provides a number of references describing a number of ways 604 in which the information leakage produced by a vulnerable 605 implementation could be leveraged by an attacker. This section 606 describes a specific network scenario in which a vulnerable 607 implementation could possibly leak the current Fragment 608 Identification value in use by a third-party host to send fragmented 609 datagrams to the vulnerable implementation. 611 For the most part, this section is included to illustrate how a 612 vulnerable implementation might be leveraged to leak-out the 613 Fragment Identification value of an otherwise secure 614 implementation. This section might be removed in future revisions 615 of this document. 617 The following scenarios assume: 619 A: 620 Is an IPv6 host that implements the recommended Fragment 621 Identification algorithm (Section 5.1), implements [RFC5722], but 622 does not implement [I-D.ietf-6man-ipv6-atomic-fragments]. 624 B: 625 Victim node. Selected the Fragment Identification values from a 626 global counter. 628 C: 629 Attacker. Can forge the IPv6 Source Address of his packets at 630 will. 632 If the attacker sends forged SYN packets to a closed TCP port, and 633 then fails when trying to produce a collision of Fragment 634 Identifications (see line #4), the following packet exchange might 635 take place: 637 A B C 639 #1 <------ Echo Req #1 ---------- 640 #2 --- Echo Resp #1, FID=5000 ---> 641 #3 <------------------- SYN #1, src= B ----------------------- 642 #4 <---- SYN/ACK, FID=42 src = A--- 643 #5 ---- SYN/ACK, FID=9000 ---> 644 #6 <---- RST, FID= 5001 ----- 645 #7 <---- RST, FID= 5002 ----- 646 #8 <-------- Echo Req #2 ---------- 647 #9 ---- Echo Resp #2, FID= 5003 --> 649 On the other hand, if the attacker succeeds to produce a collision of 650 Fragment Identification values, the following packet exchange could 651 take place: 653 A B C 655 #1 <------- Echo Req #1 ---------- 656 #2 ---- Echo Resp #1, FID=5000 ---> 657 #3 <------------------- SYN #1, src= B ----------------------- 658 #4 <-- SYN/ACK, FID=9000 src=A --- 659 #5 ---- SYN/ACK, FID=9000 ---> 660 ... (RFC5722) ... 661 #6 <-------- Echo Req #2 ---------- 662 #7 ---- Echo Resp #2, FID= 5001 --> 664 Clearly, the Fragment Identification value sampled by from the second 665 ICMPv6 Echo Response packet ("Echo Resp #2") implicitly indicates 666 whether the Fragment Identification in the forged SYN/ACK (see line 667 #4 in both figures) was the current Fragment Identification in use by 668 Host A. 670 As a result, the attacker could employ this technique to learn the 671 current Fragment Identification value used by host A to send packets 672 to host B. 674 Appendix B. Survey of Fragment Identification selection algorithms 675 employed by popular IPv6 implementations 677 This section includes a survey of the Fragment Identification 678 selection algorithms employed in some popular operating systems. 680 The survey was produced with the SI6 Networks IPv6 toolkit 681 [SI6-IPv6]. 683 +-----------------------+-------------------------------------------+ 684 | Operating System | Algorithm | 685 +-----------------------+-------------------------------------------+ 686 | FreeBSD 9.0 | Unpredictable (Random) | 687 +-----------------------+-------------------------------------------+ 688 | Linux 3.0.0-15 | Predictable (Global Counter, Init=0, | 689 | | Incr=1) | 690 +-----------------------+-------------------------------------------+ 691 | Linux-current | Unpredictable (Per-dest Counter, | 692 | | Init=random, Incr=1) | 693 +-----------------------+-------------------------------------------+ 694 | NetBSD 5.1 | Unpredictable (Random) | 695 +-----------------------+-------------------------------------------+ 696 | OpenBSD-current | Random (SKIP32) | 697 +-----------------------+-------------------------------------------+ 698 | Solaris 10 | Predictable (Per-dst Counter, Init=0, | 699 | | Incr=1) | 700 +-----------------------+-------------------------------------------+ 701 | Windows XP SP2 | Predictable (Global Counter, Init=0, | 702 | | Incr=2) | 703 +-----------------------+-------------------------------------------+ 704 | Windows Vista (Build | Predictable (Global Counter, Init=0, | 705 | 6000) | Incr=2) | 706 +-----------------------+-------------------------------------------+ 707 | Windows 7 Home | Predictable (Global Counter, Init=0, | 708 | Premium | Incr=2) | 709 +-----------------------+-------------------------------------------+ 711 Table 1: Fragment Identification algorithms employed by different 712 OSes 714 In the text above, "predictable" should be taken as "easily 715 guessable by an off-path attacker, by sending a few probe 716 packets". 718 Author's Address 720 Fernando Gont 721 SI6 Networks / UTN-FRH 722 Evaristo Carriego 2644 723 Haedo, Provincia de Buenos Aires 1706 724 Argentina 726 Phone: +54 11 4650 8472 727 Email: fgont@si6networks.com 728 URI: http://www.si6networks.com