idnits 2.17.1 draft-ietf-6man-predictable-fragment-id-00.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 (March 22, 2013) is 4046 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) March 22, 2013 5 Intended status: BCP 6 Expires: September 23, 2013 8 Security Implications of Predictable Fragment Identification Values 9 draft-ietf-6man-predictable-fragment-id-00 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. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 23, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Security Implications of Predictable Fragment 65 Identification values . . . . . . . . . . . . . . . . . . . . 4 66 3. Updating RFC 2460 . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Constraints for the selection of Fragment Identification 68 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Algorithms for Selecting Fragment Identification Values . . . 10 70 5.1. Per-destination counter (initialized to a random value) . 10 71 5.2. Randomized Identification values . . . . . . . . . . . . . 11 72 5.3. Hash-based Fragment Identification selection algorithm . . 11 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Appendix A. Information leakage produced by vulnerable 80 implementations . . . . . . . . . . . . . . . . . . . 19 81 Appendix B. Survey of Fragment Identification selection 82 algorithms employed by popular IPv6 83 implementations . . . . . . . . . . . . . . . . . . . 21 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 IPv6 specifies the Fragment Header, which is employed for the 89 fragmentation and reassembly mechanisms. The Fragment Header 90 contains an "Identification" field which, together with the IPv6 91 Source Address and the IPv6 Destination Address of the packet, 92 identifies fragments that correspond to the same original datagram, 93 such that they can be reassembled together at the receiving host. 94 The only requirement for setting the "Identification" value is that 95 it must be different than that of any other fragmented packet sent 96 recently with the same Source Address and Destination Address. 98 The most trivial algorithm to avoid reusing Fragment Identification 99 values too quickly is to maintain a global counter that is 100 incremented for each fragmented packet that is sent. However, this 101 trivial algorithm leads to predictable Identification values, which 102 can be leveraged for performing a variety of attacks. 104 Section 2 of this document analyzes the security implications of 105 predictable Identification values. Section 3 updates RFC 2460 by 106 adding the requirement that Identification values not be predictable 107 by an off-path attacker. Section 4 discusses constraints in the 108 possible algorithms for selecting Fragment Identification values. 109 Section 5 specifies a number of algorithms that could be used for 110 generating Identification values. Finally, Appendix B contains a 111 survey of the Fragment Identification algorithms employed by popular 112 IPv6 implementations. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Security Implications of Predictable Fragment Identification values 120 Predictable Identification values result in an information leakage 121 that can be exploited in a number of ways. Among others, they may 122 potentially be exploited to: 124 o determine the packet rate at which a given system is transmitting 125 information, 127 o perform stealth port scans to a third-party, 129 o uncover the rules of a number of firewalls, 131 o count the number of systems behind a middle-box, or, 133 o perform a Denial of Service (DoS) attack 135 [CPNI-IPv6] contains a detailed analysis of possible vulnerabilities 136 introduced by predictable Fragment Identification values. In 137 summary, their security implications are very similar to those of 138 predictable Identification values in IPv4. 140 [Sanfilippo1998a] originally pointed out how the IPv4 141 Identification field could be examined to determine the packet 142 rate at which a given system is transmitting information. Later, 143 [Sanfilippo1998b] described how a system with such an 144 implementation could be used to perform a stealth port scan to a 145 third (victim) host. [Sanfilippo1999] explained how to exploit 146 this implementation strategy to uncover the rules of a number of 147 firewalls. [Bellovin2002] explains how the IPv4 Identification 148 field can be exploited to count the number of systems behind a 149 NAT. [Fyodor2004] is an entire paper on most (if not all) the 150 ways to exploit the information provided by the Identification 151 field of the IPv4 header (and these results apply in a similar way 152 to IPv6). [RFC6274] covers the security implications of IPv4 in 153 detail. 155 One key difference between the IPv4 case and the IPv6 case is that in 156 IPv4 the Identification field is part of the fixed IPv4 header (and 157 thus usually set for all packets), while in IPv6 the Identification 158 field is set only in those packets that employ a Fragment Header. As 159 a result, successful exploitation of the Identification field against 160 communication instances with arbitrary destinations depends on two 161 different factors: 163 o IPv6 implementations using predictable Identification values, and, 164 o the ability of the attacker to cause the victim host to fragment 165 packets destined to other nodes 167 As noted in the previous section, some implementations are known to 168 use predictable identification values. 170 For example, Linux 2.6.38-8 sets the Identification field 171 according to a global counter that is incremented by one for each 172 datagram that is sent with a fragment header (either a single 173 fragment or as multiple fragments). 175 Finally, we note that an attacker could cause a victim host to 176 fragment its outgoing packets by sending it a forged ICMPv6 'Packet 177 Too Big' error message advertising a Next-Hop MTU smaller than 1280 178 bytes. 180 RFC 1981 [RFC1981] states that when an ICMPv6 Packet Too Big error 181 message with an MTU smaller than 1280 bytes is received, the 182 receiving host is not required to reduce the Path-MTU for the 183 corresponding destination address, but must simply include a 184 Fragment Header in all subsequent packets sent to that 185 destination. In order to make sure that the forged ICMPv6 Packet 186 Too Big error message triggers fragmentation at the victim host, 187 the attacker could set the MTU field of the error message to a 188 value smaller than 1280 bytes. Since the minimum IPv6 MTU is 1280 189 bytes, such value would always be smaller than the Path-MTU in use 190 for that destination. 192 There are a few issues that should be considered, though: 194 o In all the implementations the author is aware of, an attacker can 195 only cause the victim to enable fragmentation on a per-destination 196 basis. That is, the victim will use fragmentation only for those 197 packets sent to the Source Address of IPv6 packet embedded in the 198 payload of the ICMPv6 Packet Too Big error message. 200 Section 5.2 of [RFC1981] notes that an implementation could 201 maintain a single system-wide PMTU value to be used for all 202 packets originating from that nodes. Clearly, such an 203 implementations would exacerbate the problem of any attacks 204 based on PMTUD [RFC5927] or IPv6 fragmentation. 206 o If the victim node implements some of the counter-measures for 207 ICMP attacks described in RFC 5927 [RFC5927], it might be 208 difficult for an attacker to cause the victim node to use 209 fragmentation for its outgoing packets. 211 Some implementations do not incorporate countermeasures for 212 attacks based on ICMPv6 error messages. For example, Linux 213 2.6.38-8 does not even require received ICMPv6 error messages 214 to correspond to ongoing communication instances. 216 Implementations that employ predictable Identification values and 217 also fail to include countermeasures against attacks based on ICMPv6 218 error messages will be vulnerable to attacks similar to those based 219 on the IPv4 Identification field for IPv4 networks, such as the 220 stealth port-scanning technique described in [Sanfilippo1998b]. 222 One possible way in which predictable Identification values could be 223 leveraged for performing a Denial of Service (DoS) attack is as 224 follows: once the Identification value currently in use at the victim 225 host has been learned, the attacker would send a forged ICMPv6 Packet 226 Too Big error message to the victim host, with the IPv6 Destination 227 Address of the embedded IPv6 packet set to the IPv6 address of a 228 third-party host with which the victim is communicating. This ICMPv6 229 Packet Too Big error message would cause any packets sent from the 230 victim to the third-party host to include a Fragment Header. The 231 attacker would then send forged IPv6 fragments to the third-party 232 host, with their IPv6 Source Address set to that of the victim host, 233 and with the Identification field of the forged fragments set to 234 values that would result in collisions at the third-party host. If 235 the third-party host discards fragments that result in collisions of 236 Identification values, the attacker could simply trash the 237 Identification space by sending multiple forged fragments with 238 different Identification values, such that any subsequent packets 239 from the victim host are discarded at the third-party host as a 240 result of the malicious fragments sent by the attacker. 242 For example, Linux 2.6.38-10 is vulnerable to the aforementioned 243 issue. 245 [I-D.ietf-6man-ipv6-atomic-fragments] describes an improved 246 processing of these packets that would eliminate this specific 247 attack vector, at least in the case of TCP connections that employ 248 the Path-MTU Discovery mechanism. 250 The aforementioned attack scenario is simply included to illustrate 251 the problem of employing predictable fragment Identification values, 252 rather than to indicate a specific attack vector that needs to be 253 mitigated. 255 We note that regardless of the attacker's ability to cause a victim 256 host to employ fragmentation when communicating with third-parties, 257 use of predictable Identification values makes communication flows 258 that employ fragmentation vulnerable to any fragmentation-based 259 attacks. 261 3. Updating RFC 2460 263 Hereby we update RFC 2460 [RFC2460] as follows: 265 The Identification value of the Fragment Header MUST NOT be 266 predictable by an off-path attacker. 268 4. Constraints for the selection of Fragment Identification Values 270 the "Identification" field of the Fragmentation Header is 32-bits 271 long. However, when translators [RFC6145] are employed, the 272 "effective" length of the IPv6 Fragment Identification field is 16 273 bits. 275 [RFC6145] notes that, when translating in the IPv6-to-IPv4 276 direction, "if there is a Fragment Header in the IPv6 packet, the 277 last 16 bits of its value MUST be used for the IPv4 identification 278 value". This means that the high-order 16 bits are effectively 279 ignored. 281 As a result, at least during the IPv6/IPv4 transition/co-existence 282 phase, it is probably safer to assume that only the last 16 bits of 283 the IPv6 Fragment Identification may be used in some cases. 285 Regarding the selection of Fragment Identification values, the only 286 requirement specified in [RFC2460] is that the Fragment 287 Identification must be different than that of any other fragmented 288 packet sent recently with the same Source Address and Destination 289 Address. 291 Failure to comply with that requirement might lead to the 292 interoperability problems discussed in [RFC4963]. 294 From a security standpoint, unpredictable Identification values are 295 desirable. However, this is somewhat at odds with the "re-use" 296 requirements specified in [RFC2460]. 298 Finally, since Fragment Identification values need to be selected for 299 each outgoing datagram that requires fragmentation, the performance 300 aspect should be considered when choosing an algorithm for the 301 selection of Fragment Identification values. 303 5. Algorithms for Selecting Fragment Identification Values 305 This section specifies a number of algorithms that MAY be used for 306 selecting Fragment Identification values. 308 5.1. Per-destination counter (initialized to a random value) 310 1. Whenever a packet must be sent with a Fragment Header, the 311 sending host should perform a look-up in the Destinations Cache 312 an entry corresponding to the intended Destination Address. 314 2. If such an entry exists, it contains the last Fragment 315 Identification value used for that Destination. Therefore, such 316 value should be incremented by 1, and used for setting the 317 Fragment Identification value of the outgoing packet. 318 Additionally, the updated value should be recorded in the 319 corresponding entry of the Destination Cache. 321 3. If such an entry does not exist, it should be created, and the 322 "Identification" value for that destination should be initialized 323 with a random value (e.g., with a pseudorandom number generator), 324 and used for setting the Identification field of the Fragment 325 Header of the outgoing packet. 327 The advantages of this algorithm are: 329 o It is simple to implement, with the only complexity residing in 330 the Pseudo-Random Number Generator (PRNG) used to initialize the 331 "Identification" value contained in each entry of the Destinations 332 Cache. 334 o The "Identification" re-use frequency will typically be lower than 335 that achieved by a global counter (when sending traffic to 336 multiple destinations), since this algorithm uses per-destination 337 counters (rather than a single system-wide counter). 339 o It has good performance properties (once the corresponding entry 340 in the Destinations Cache has been created, each subsequent 341 "Identification" value simply involves the increment of a 342 counter). 344 The possible drawbacks of this algorithm are: 346 o If as a result of resource management an entry of the Destinations 347 Cache must be removed, the last Fragment Identification value used 348 for that Destination is obviously lost. Thus, if subsequent 349 traffic to that destination causes the aforementioned entry to be 350 re-created, the Fragment Identification value will be randomized, 351 thus possibly leading to Fragment Identification "collisions". 353 o Since the Fragment Identification values are predictable by the 354 destination host, a vulnerable host might possible leak to third- 355 parties the Fragment Identification values used by other hosts to 356 send traffic to it (i.e., Host B could leak to Host C the Fragment 357 Identification values that Host A is using to send packets to Host 358 B). 360 Appendix A describes a scenario in which that information 361 leakage could take place. 363 5.2. Randomized Identification values 365 Clearly, use of a Pseudo-Random Number Generator for selecting the 366 Fragment Identification could be desirable from a security 367 standpoint. With such a scheme, the Fragment Identification of each 368 fragmented datagram would be selected as: 370 Identification = random() 372 where "random()" is the PRNG. 374 The specific properties of such scheme would clearly depend on the 375 specific PRNG algorithm used. For example, some PRNGs may result in 376 higher Fragment Identification reuse frequencies than others, in the 377 same way as some PRNGs may be more expensive (in terms of processing 378 requirements and/or implementation complexity) than others. 380 Discussion of the properties of possible PRNGs is considered out of 381 the scope of this document. However, we do note that some PRNGs 382 employed in the past by some implementations have been found to be 383 predictable [Klein2007]. Please see [RFC4086] for randomness 384 requirements for security. 386 5.3. Hash-based Fragment Identification selection algorithm 388 Another alternative is to implement a hash-based algorithm similar to 389 that specified in for the selection of transport port numbers. With 390 such a scheme, the Fragment Identification value of each fragment 391 datagram would be selected with the expression: 393 Identification = F(Src IP, Dst IP, secret1) + 394 counter[G(src IP, Dst Pref, secret2)] 396 where: 398 Identification: 399 Identification value to be used for the fragmented datagram 401 F(): 402 Hash function 404 Src IP: 405 IPv6 Source Address of the datagram to be fragmented 407 Dst IP: 408 IPv6 Destination Address of the datagram to be fragmented 410 secret1: 411 Secret data unknown to the attacker 413 counter[]: 414 System-wide array of 32-bit counters (e.g. with 8K elements or 415 more) 417 G(): 418 Hash function. May or may not be the same hash function as that 419 used for F() 421 Dst Pref: 422 IPv6 "Destination Prefix" of datagram to be fragmented (can be 423 assumed to be the first eight bytes of the Destination Address of 424 such packet). Note: the "Destination Prefix" (rather than 425 Destination Address) is used, such that the ability of an attacker 426 of searching the "increments" space by using multiple addresses of 427 the same subnet is reduced. 429 secret1: 430 Secret data unknown to the attacker 432 Note: counter[G(src IP, Dst Pref, secret2)] should be incremented by 433 one each time an Identification value is selected. 435 The advantages of this algorithm are: 437 o The "Identification" re-use frequency will typically be lower than 438 that achieved by a global counter (when sending traffic to 439 multiple destinations), since this algorithm uses multiple system- 440 wide counters (rather than a single system-wide counter). The 441 extent to which the re-use frequency will be lower will depend on 442 the number of elements in counter[], and the number of other 443 active flows that result in the same value of G() (and hence cause 444 the same counter to be incremented for each fragmented datagram 445 that is sent). 447 o It is possible to implement the algorithm such that good 448 performance is achieved. For example, the result of F() could be 449 stored in the Destinations Cache (such that it need not be 450 recomputed for each packet that must be sent) along with computed 451 *index* for counter[]. 453 It should be noted that if this implementation approach is 454 followed, and an entry of the Destinations Cache must be 455 removed as a result of resource management, the last Fragment 456 Identification value used for that Destination will *not* lost. 457 This is an improvement over the algorithm specified in 458 Section 5.1. 460 The possible drawbacks of this algorithm are: 462 o Since the Fragment Identification values are predictable by the 463 destination host, a vulnerable host could possibly leak to third- 464 parties the Fragment Identification values used by other hosts to 465 send traffic to it (i.e., Host B could leak to Host C the Fragment 466 Identification values that Host A is using to send packets to Host 467 B). 469 Appendix A describes a scenario in which that information 470 leakage could take place. We note, however, that this 471 algorithm makes the aforementioned attack less reliable for the 472 attacker, since each counter could be possibly shared by 473 multiple traffic flows (i.e., packets destined to other 474 destinations might cause the counter to be incremented). 476 This algorithm might be preferable (over the one specified in 477 Section 5.1) in those scenarios in which a node is expected to 478 communicate with a large number of destinations, and thus it is 479 desirable to limit the amount of information to be maintained in 480 memory. 482 In such scenarios, if the algorithm specified in Section 5.1 were 483 implemented, entries from the Destinations Cache might need to be 484 pruned frequently, thus increasing the risk of fragment 485 Identification collisions. 487 6. IANA Considerations 489 There are no IANA registries within this document. The RFC-Editor 490 can remove this section before publication of this document as an 491 RFC. 493 7. Security Considerations 495 This document discusses the security implications of predictable 496 Fragment Identification values, and updates RFC 2460 such that 497 Fragment Identification values are required to be unpredictable by 498 off-path attackers, hence mitigating the aforementioned security 499 implications. 501 A number of possible algorithms are specified, to provide some 502 implementation alternatives to implementers. However, the selection 503 of an specific algorithm that complies with Section 3 is left to 504 implementers. We note that the selection of such an algorithm 505 usually implies a number of trade-offs (security, performance, 506 implementation complexity, interoperability properties, etc.). 508 8. Acknowledgements 510 The author would like to thank Ivan Arce for proposing the attack 511 scenario described in Appendix A, and for providing valuable comments 512 on earlier versions of this document. 514 The author would like to thank Dave Thaler for providing valuable 515 comments on earlier versions of this document. 517 This document is based on the technical report "Security Assessment 518 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 519 Fernando Gont on behalf of the UK Centre for the Protection of 520 National Infrastructure (CPNI). 522 Fernando Gont would like to thank the UK CPNI 523 (http://www.cpni.gov.uk) for their continued support. 525 9. References 527 9.1. Normative References 529 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 530 for IP version 6", RFC 1981, August 1996. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 536 (IPv6) Specification", RFC 2460, December 1998. 538 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 539 Requirements for Security", BCP 106, RFC 4086, June 2005. 541 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 542 RFC 5722, December 2009. 544 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 545 Algorithm", RFC 6145, April 2011. 547 9.2. Informative References 549 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 550 Errors at High Data Rates", RFC 4963, July 2007. 552 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 554 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 555 Version 4", RFC 6274, July 2011. 557 [I-D.ietf-6man-ipv6-atomic-fragments] 558 Gont, F., "Processing of IPv6 "atomic" fragments", 559 draft-ietf-6man-ipv6-atomic-fragments-04 (work in 560 progress), March 2013. 562 [Bellovin2002] 563 Bellovin, S., "A Technique for Counting NATted Hosts", 564 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 566 [CPNI-IPv6] 567 Gont, F., "Security Assessment of the Internet Protocol 568 version 6 (IPv6)", UK Centre for the Protection of 569 National Infrastructure, (available on request). 571 [Fyodor2004] 572 Fyodor, "Idle scanning and related IP ID games", 2004, 573 . 575 [Klein2007] 576 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 577 Predictable IP ID Vulnerability", 2007, . 582 [Sanfilippo1998a] 583 Sanfilippo, S., "about the ip header id", Post to Bugtraq 584 mailing-list, Mon Dec 14 1998, 585 . 587 [Sanfilippo1998b] 588 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 589 1998, . 591 [Sanfilippo1999] 592 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 593 list, 1999, 594 . 596 [SI6-IPv6] 597 "SI6 Networks' IPv6 toolkit", 598 . 600 Appendix A. Information leakage produced by vulnerable implementations 602 Section 2 provides a number of references describing a number of ways 603 in which the information leakage produced by a vulnerable 604 implementation could be leveraged by an attacker. This section 605 describes a specific network scenario in which a vulnerable 606 implementation could possibly leak the current Fragment 607 Identification value in use by a third-party host to send fragmented 608 datagrams to the vulnerable implementation. 610 For the most part, this section is included to illustrate how a 611 vulnerable implementation might be leveraged to leak-out the 612 Fragment Identification value of an otherwise secure 613 implementation. This section might be removed in future revisions 614 of this document. 616 The following scenarios assume: 618 A: 619 Is an IPv6 host that implements the recommended Fragment 620 Identification algorithm (Section 5.1), implements [RFC5722], but 621 does not implement [I-D.ietf-6man-ipv6-atomic-fragments]. 623 B: 624 Victim node. Selected the Fragment Identification values from a 625 global counter. 627 C: 628 Attacker. Can forge the IPv6 Source Address of his packets at 629 will. 631 If the attacker sends forged SYN packets to a closed TCP port, and 632 then fails when trying to produce a collision of Fragment 633 Identifications (see line #4), the following packet exchange might 634 take place: 636 A B C 638 #1 <------ Echo Req #1 ---------- 639 #2 --- Echo Resp #1, FID=5000 ---> 640 #3 <------------------- SYN #1, src= B ----------------------- 641 #4 <---- SYN/ACK, FID=42 src = A--- 642 #5 ---- SYN/ACK, FID=9000 ---> 643 #6 <---- RST, FID= 5001 ----- 644 #7 <---- RST, FID= 5002 ----- 645 #8 <-------- Echo Req #2 ---------- 646 #9 ---- Echo Resp #2, FID= 5003 --> 648 On the other hand, if the attacker succeeds to produce a collision of 649 Fragment Identification values, the following packet exchange could 650 take place: 652 A B C 654 #1 <------- Echo Req #1 ---------- 655 #2 ---- Echo Resp #1, FID=5000 ---> 656 #3 <------------------- SYN #1, src= B ----------------------- 657 #4 <-- SYN/ACK, FID=9000 src=A --- 658 #5 ---- SYN/ACK, FID=9000 ---> 659 ... (RFC5722) ... 660 #6 <-------- Echo Req #2 ---------- 661 #7 ---- Echo Resp #2, FID= 5001 --> 663 Clearly, the Fragment Identification value sampled by from the second 664 ICMPv6 Echo Response packet ("Echo Resp #2") implicitly indicates 665 whether the Fragment Identification in the forged SYN/ACK (see line 666 #4 in both figures) was the current Fragment Identification in use by 667 Host A. 669 As a result, the attacker could employ this technique to learn the 670 current Fragment Identification value used by host A to send packets 671 to host B. 673 Appendix B. Survey of Fragment Identification selection algorithms 674 employed by popular IPv6 implementations 676 This section includes a survey of the Fragment Identification 677 selection algorithms employed in some popular operating systems. 679 The survey was produced with the SI6 Networks IPv6 toolkit 680 [SI6-IPv6]. 682 +-----------------------+-------------------------------------------+ 683 | Operating System | Algorithm | 684 +-----------------------+-------------------------------------------+ 685 | FreeBSD 9.0 | Unpredictable (Random) | 686 +-----------------------+-------------------------------------------+ 687 | Linux 3.0.0-15 | Predictable (Global Counter, Init=0, | 688 | | Incr=1) | 689 +-----------------------+-------------------------------------------+ 690 | Linux-current | Unpredictable (Per-dest Counter, | 691 | | Init=random, Incr=1) | 692 +-----------------------+-------------------------------------------+ 693 | NetBSD 5.1 | Unpredictable (Random) | 694 +-----------------------+-------------------------------------------+ 695 | OpenBSD-current | Random (SKIP32) | 696 +-----------------------+-------------------------------------------+ 697 | Solaris 10 | Predictable (Per-dst Counter, Init=0, | 698 | | Incr=1) | 699 +-----------------------+-------------------------------------------+ 700 | Windows XP SP2 | Predictable (Global Counter, Init=0, | 701 | | Incr=2) | 702 +-----------------------+-------------------------------------------+ 703 | Windows Vista (Build | Predictable (Global Counter, Init=0, | 704 | 6000) | Incr=2) | 705 +-----------------------+-------------------------------------------+ 706 | Windows 7 Home | Predictable (Global Counter, Init=0, | 707 | Premium | Incr=2) | 708 +-----------------------+-------------------------------------------+ 710 Table 1: Fragment Identification algorithms employed by different 711 OSes 713 In the text above, "predictable" should be taken as "easily 714 guessable by an off-path attacker, by sending a few probe 715 packets". 717 Author's Address 719 Fernando Gont 720 SI6 Networks / UTN-FRH 721 Evaristo Carriego 2644 722 Haedo, Provincia de Buenos Aires 1706 723 Argentina 725 Phone: +54 11 4650 8472 726 Email: fgont@si6networks.com 727 URI: http://www.si6networks.com