idnits 2.17.00 (12 Aug 2021) /tmp/idnits20480/draft-ietf-6man-predictable-fragment-id-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2015) is 2409 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: draft-ietf-6man-deprecate-atomfrag-generation has been published as RFC 8021 Summary: 3 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 October 9, 2015 5 Expires: April 11, 2016 7 Security Implications of Predictable Fragment Identification Values 8 draft-ietf-6man-predictable-fragment-id-10 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 by the receiving host. 18 The only requirement for setting the "Identification" field is that 19 the corresponding value must be different than that employed for any 20 other fragmented packet sent recently with the same Source Address 21 and Destination Address. Some implementations use a simple global 22 counter for setting the Identification field, thus leading to 23 predictable Identification values. This document analyzes the 24 security implications of predictable Identification values, and 25 provides implementation guidance for selecting the Identification 26 field of the Fragment Header, such that the aforementioned security 27 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 April 11, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Security Implications of Predictable Fragment Identification 66 values . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Constraints for the selection of Fragment Identification 68 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Algorithms for Selecting Fragment Identification Values . . . 7 70 5.1. Per-destination counter (initialized to a random value) . 8 71 5.2. Randomized Identification values . . . . . . . . . . . . 9 72 5.3. Hash-based Fragment Identification selection algorithm . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Appendix A. Information leakage produced by vulnerable 80 implementations . . . . . . . . . . . . . . . . . . 15 81 Appendix B. Survey of Fragment Identification selection 82 algorithms employed by popular IPv6 implementations 17 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 IPv6 specifies the Fragment Header, which is employed for the 88 fragmentation and reassembly mechanisms. The Fragment Header 89 contains an "Identification" field which, together with the IPv6 90 Source Address and the IPv6 Destination Address of a packet, 91 identifies fragments that correspond to the same original datagram, 92 such that they can be reassembled together at the receiving host. 93 The only requirement for setting the "Identification" value is that 94 it must be different than that employed for any other fragmented 95 packet sent recently with the same Source Address and Destination 96 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 transmitted. However, 101 this trivial algorithm leads to predictable Identification values, 102 which can be leveraged to perform a variety of attacks. 104 Section 3 of this document analyzes the security implications of 105 predictable Identification values. Section 4 discusses constraints 106 in the possible algorithms for selecting Fragment Identification 107 values. Section 5 specifies a number of algorithms that could be 108 used for generating Identification values. Finally, Appendix B 109 contains a survey of the Fragment Identification algorithms employed 110 by popular IPv6 implementations. 112 2. Terminology 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 3. 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, 133 o perform Denial of Service (DoS) attacks, or, 135 o perform data injection attacks against transport or application 136 protocols 138 The security implications introduced by predictable Fragment 139 Identification values are very similar to those of predictable 140 Identification values in IPv4. 142 [Sanfilippo1998a] originally pointed out how the IPv4 143 Identification field could be examined to determine the packet 144 rate at which a given system is transmitting information. Later, 145 [Sanfilippo1998b] described how a system with such an 146 implementation could be used to perform a stealth port scan to a 147 third (victim) host. [Sanfilippo1999] explains how to exploit 148 this implementation strategy to uncover the rules of a number of 149 firewalls. [Bellovin2002] explains how the IPv4 Identification 150 field can be exploited to count the number of systems behind a 151 NAT. [Fyodor2004] is an entire paper on most (if not all) the 152 ways to exploit the information provided by the Identification 153 field of the IPv4 header (and these results apply in a similar way 154 to IPv6). [Zalewski2003] originally envisioned the exploitation 155 of IP fragmentation/reassembly for performing data injection 156 attacks against upper-layer protocols. [Herzberg2013] explores 157 the use of IPv4/IPv6 fragmentation and predictable Identification 158 values for performing DNS cache poisoning attacks in great detail. 159 [RFC6274] covers the security implications of the IPv4 case in 160 detail. 162 One key difference between the IPv4 case and the IPv6 case is that in 163 IPv4 the Identification field is part of the fixed IPv4 header (and 164 thus usually set for all packets), while in IPv6 the Identification 165 field is present only in those packets that carry a Fragment Header. 166 As a result, successful exploitation of the IPv6 Fragment 167 Identification field depends on two different factors: 169 o vulnerable IPv6 Fragment Identification generators, and, 171 o the ability of an attacker to trigger the use of IPv6 172 fragmentation for packets sent from/to the victim node 174 The scenarios in which an attacker may successfully perform the 175 aforementioned attacks depend on the specific attack type. For 176 example, in order to DoS communications between two hosts, an 177 attacker would need to know the IPv6 addresses employed by the 178 aforementioned two nodes. Such knowledge may be readily available if 179 the target of the attack is the communication between two specific 180 BGP peers, two specific SMTP servers, or one specific primary DNS 181 server and one of its secondary DNS servers, but may not be easily 182 available if goal of the attack is to DoS all communications between 183 arbitrary IPv6 hosts (e.g. the goal was to DoS all communications 184 involving one specific node with arbitrary/unknown hosts). Other 185 attacks, such as performing stealth port scans to a third-party or 186 determining the packet rate at which a given system is transmitting 187 information, only require the attacker to know the IPv6 address of a 188 vulnerable implementation. 190 As noted in the previous section, some implementations have been 191 known to use predictable Fragment Identification values. For 192 instance, Appendix B of this document shows that recent versions of a 193 number of popular IPv6 implementations employ predictable values for 194 the IPv6 Fragment Identification. 196 Additionally, we note that [RFC2460] states that when an ICMPv6 197 Packet Too Big (PTB) error message advertising a Maximum Transfer 198 Unit (MTU) smaller than 1280 bytes is received, the receiving host is 199 not required to reduce the Path-MTU for the corresponding Destination 200 Address, but must simply include a Fragment Header in all subsequent 201 packets sent to that destination. This triggers the use of the so- 202 called IPv6 "atomic fragments" [RFC6946]: IPv6 fragments with a 203 Fragment Offset equal to 0, and the "M" ("More fragments") bit clear. 204 [I-D.ietf-6man-deprecate-atomfrag-generation] aims at deprecating the 205 generation of IPv6 atomic fragments. 207 Thus, an attacker can usually cause a victim host to "fragment" its 208 outgoing packets by sending it a forged ICMPv6 'Packet Too Big' (PTB) 209 error message that advertises an MTU smaller than 1280 bytes. 211 There are a number of aspects that should be considered, though: 213 o All the implementations the author is aware of record the Path-MTU 214 information on a per-destination basis. Thus, an attacker can 215 only cause the victim to enable fragmentation for those packets 216 sent to the Source Address of IPv6 packet embedded in the payload 217 of the ICMPv6 PTB message. However, we note that Section 5.2 of 218 [RFC1981] notes that an implementation could maintain a single 219 system-wide PMTU value to be used for all packets sent to that 220 node. Clearly, such implementations would exacerbate the problem 221 of any attacks based on PMTUD [RFC5927] or IPv6 fragmentation. 223 o If the victim node implements some of the counter-measures for 224 ICMP attacks described in RFC 5927 [RFC5927], it might be 225 difficult for an attacker to cause the victim node to employ 226 fragmentation for its outgoing packets. However, many current 227 implementations fail to enforce these validation checks. For 228 example, Linux 2.6.38-8 does not even require received ICMPv6 229 error messages to correspond to an ongoing communication instance. 231 o Some implementations (notably Linux) have already been updated 232 according to [I-D.ietf-6man-deprecate-atomfrag-generation] such 233 that ICMPv6 PTB messages do not result in the generation of IPv6 234 atomic fragments. 236 Implementations that employ predictable Identification values and 237 also fail to enforce validation checks on ICMPv6 error messages 238 become vulnerable to the same type of attacks that can be exploited 239 with IPv4 fragmentation, discussed earlier in this section. 241 One possible way in which predictable Identification values could be 242 leveraged for performing a DoS attack is as follows: Let us assume 243 that Host A is communicating with Host B, and that an attacker wants 244 to DoS attack such communication. The attacker would learn the 245 Identification value currently in use by Host A, possibly by sending 246 any packet that would elicit a fragmented response (e.g., an ICPMv6 247 echo request with a large payload). The attacker would then send a 248 forged ICMPv6 PTB error message to Host A (with the IPv6 Destination 249 Address of the embedded IPv6 packet set to the IPv6 address of a Host 250 B), such that any subsequent packets sent by Host A to Host B include 251 a Fragment Header. Finally, the attacker would send forged IPv6 252 fragments to Host B, with their IPv6 Source Address set to that of 253 Host A, and Identification values that would result in collisions 254 with the Identification values employed for the legitimate traffic 255 sent by Host A to Host B. If Host B discards fragments that result 256 in collisions of Identification values (e.g., such fragments overlap, 257 and the host implements [RFC5722]), the attacker could simply trash 258 the Identification space by sending multiple forged fragments with 259 different Identification values, such that any subsequent packets 260 from Host A to Host B are discarded at Host B as a result of the 261 malicious fragments sent by the attacker. 263 NOTES: 265 For example, Linux 2.6.38-10 is vulnerable to the aforementioned 266 issue. 268 [RFC6946] describes an improved processing of these packets that 269 would eliminate this specific attack vector, at least in the case 270 of TCP connections that employ the Path-MTU Discovery mechanism. 272 The aforementioned attack scenario is simply included to illustrate 273 the problem of employing predictable fragment Identification values. 274 We note that regardless of the attacker's ability to cause a victim 275 host to employ fragmentation when communicating with third-parties, 276 use of predictable Identification values makes communication flows 277 that employ fragmentation vulnerable to any fragmentation-based 278 attacks. 280 4. Constraints for the selection of Fragment Identification Values 282 The "Identification" field of the Fragmentation Header is 32-bits 283 long. However, when translators (e.g. [RFC6145]) are employed, the 284 high-order 16 bits of the Identification field are effectively 285 ignored. 287 NOTES: [RFC6145] notes that, when translating in the IPv6-to-IPv4 288 direction, "if there is a Fragment Header in the IPv6 packet, the 289 last 16 bits of its value MUST be used for the IPv4 identification 290 value". 292 Additionally, Section 3.3 of [RFC6052] encourages operators to use 293 a Network-Specific Prefix (NSP) that maps the IPv4 address space 294 into IPv6. Thus, when an NSP is being used, IPv6 addresses 295 representing IPv4 nodes (reached through a stateless translator) 296 are indistinguishable from native IPv6 addresses. 298 Thus, when translators are employed, the "effective" length of the 299 IPv6 Fragment Identification field is 16 bits and, as a result, at 300 least during the IPv6/IPv4 transition/co-existence phase, it is 301 probably safer to assume that only the low-order 16 bits of the IPv6 302 Fragment Identification are of use to the destination system. 304 Regarding the selection of Fragment Identification values, the only 305 requirement specified in [RFC2460] is that the Fragment 306 Identification must be different than that of any other fragmented 307 packet sent recently with the same Source Address and Destination 308 Address. Failure to comply with this requirement could lead to the 309 interoperability problems discussed in [RFC4963]. 311 From a security standpoint, unpredictable Identification values are 312 desirable. However, this is somewhat at odds with the "re-use" 313 requirements specified in [RFC2460], that specifies that an 314 Identification value must be different than that of any other 315 fragment sent recently. 317 Finally, since Fragment Identification values need to be selected for 318 each outgoing datagram that requires fragmentation, the performance 319 impact should be considered when choosing an algorithm for the 320 selection of Fragment Identification values. 322 5. Algorithms for Selecting Fragment Identification Values 324 There are a number of algorithms that may be used for selecting 325 Fragment Identification values. This section presents three of 326 those. 328 The algorithm in Section 5.1 typically leads to a low Identification 329 re-use frequency at the expense of keeping per-destination state; 330 this algorithm only uses a PRNG (Pseudo-Random Number Generator) when 331 the host communicates with a new destination. The algorithm in 332 Section 5.2 may result in a higher Identification re-use frequency. 333 It also uses a PRNG for each datagram that needs to fragmented; hence 334 the algorithm in Section 5.1 will likely result in better performance 335 properties. Finally, the algorithm in Section 5.3 achieves a similar 336 Identification re-use frequency to that of the algorithm in 337 Section 5.1 without the need of keeping state, but possible at the 338 expense of lower per-packet performance. 340 NOTES: Since the specific algorithm to be employed for the PRNGs 341 in Section 5.1 and Section 5.2, and the specific algorithms to be 342 employed for the hash functions in Section 5.3 have not been 343 specified, it is impossible to provide a quantitative performance 344 comparison of the algorithms described in this section. 346 5.1. Per-destination counter (initialized to a random value) 348 1. Whenever a packet must be sent with a Fragment Header, the 349 sending host should look-up in the Destinations Cache an entry 350 corresponding to the Destination Address of the packet. 352 2. If such an entry exists, it contains the last Fragment 353 Identification value used for that Destination Address. 354 Therefore, such value should be incremented by 1, and used for 355 setting the Fragment Identification value of the outgoing packet. 356 Additionally, the updated value should be recorded in the 357 corresponding entry of the Destination Cache [RFC4861]. 359 3. If such an entry does not exist, it should be created, and the 360 "Identification" value for that destination should be initialized 361 with a random value (e.g., with a pseudorandom number generator), 362 and used for setting the Identification field of the Fragment 363 Header of the outgoing fragmented datagram. 365 The advantages of this algorithm are: 367 o It is simple to implement, with the only complexity residing in 368 the PRNG used to initialize the "Identification" value contained 369 in each entry of the Destinations Cache. 371 o The "Identification" re-use frequency will typically be lower than 372 that achieved by a global counter (when sending traffic to 373 multiple destinations), since this algorithm uses per-destination 374 counters (rather than a single system-wide counter). 376 o It has good performance properties (once the corresponding entry 377 in the Destinations Cache has been created and initialized, each 378 subsequent "Identification" value simply involves the increment of 379 a counter). 381 The possible drawbacks of this algorithm are: 383 o If, as a result of resource management, an entry of the 384 Destinations Cache must be removed, the last Fragment 385 Identification value used for that Destination will be lost. 386 Thus, subsequent traffic to that destination would cause that 387 entry to be re-created and re-initialized to random value, thus 388 possibly leading to Fragment Identification "collisions". 390 o Since the Fragment Identification values are predictable by the 391 destination host, a vulnerable host might possibly leak to third- 392 parties the Fragment Identification values used by other hosts to 393 send traffic to it (i.e., Host B could leak to Host C the Fragment 394 Identification values that Host A is using to send packets to Host 395 B). Appendix A describes one possible scenario for such leakage 396 in detail. 398 5.2. Randomized Identification values 400 Clearly, use of a Pseudo-Random Number Generator for selecting the 401 Fragment Identification would be desirable from a security 402 standpoint. With such a scheme, the Fragment Identification of each 403 fragmented datagram would be selected as: 405 Identification = random() 407 where "random()" is the PRNG. 409 The specific properties of such scheme would clearly depend on the 410 specific PRNG employed. For example, some PRNGs may result in higher 411 Fragment Identification reuse frequencies than others, in the same 412 way that some PRNGs may be more expensive (in terms of processing 413 requirements and/or implementation complexity) than others. 415 Discussion of the properties of possible PRNGs is considered out of 416 the scope of this document. However, we do note that some PRNGs 417 employed in the past by some implementations have been found to be 418 predictable [Klein2007]. Please see [RFC4086] for randomness 419 requirements for security. 421 5.3. Hash-based Fragment Identification selection algorithm 423 Another alternative is to implement a hash-based algorithm similar to 424 that specified in [RFC6056] for the selection of transport port 425 numbers. With such a scheme, the Fragment Identification value of 426 each fragment datagram would be selected with the expression: 428 Identification = F(Src IP, Dst IP, secret1) + 429 counter[G(Src IP, Dst Pref, secret2)] 431 where: 433 Identification: 434 Identification value to be used for the fragmented datagram 436 F(): 437 Hash function 439 Src IP: 440 IPv6 Source Address of the datagram to be fragmented 442 Dst IP: 443 IPv6 Destination Address of the datagram to be fragmented 445 secret1: 446 Secret data unknown to the attacker. This value can be 447 initialized to a pseudo-random value during the system 448 bootstrapping sequence. It should remain constant at least while 449 there could be previously-sent fragments still in the network or 450 at the fragment reassembly buffer of the corresponding destination 451 system(s). 453 counter[]: 454 System-wide array of 32-bit counters (e.g. with 8K elements or 455 more). Each counter should be initialized to a pseudo-random 456 value during the system bootstrapping sequence. 458 G(): 459 Hash function. May or may not be the same hash function as that 460 used for F() 462 Dst Pref: 463 IPv6 "Destination Prefix" of datagram to be fragmented (can be 464 assumed to be the first eight bytes of the Destination Address of 465 such packet). Note: the "Destination Prefix" (rather than 466 Destination Address) is used, such that the ability of an attacker 467 of searching the "increments" space by using multiple addresses of 468 the same subnet is reduced. 470 secret2: 471 Secret data unknown to the attacker. This value can be 472 initialized to a pseudo-random value during the system 473 bootstrapping sequence. It should remain constant at least while 474 there could be previously-sent fragments still in the network or 475 at the fragment reassembly buffer of the corresponding destination 476 system(s). 478 NOTE: counter[G(src IP, Dst Pref, secret2)] should be incremented by 479 one each time an Identification value is selected. 481 The output of F() will be constant for each (Src IP, Dst IP) pair. 482 Similarly, the output of G() will be constant for each (Src IP, Dst 483 Pref) pair. Thus, the resulting "Identification" value will be the 484 result of a random offset plus a linear function (provided by 485 counter[]), therefore resulting in a monotonically-increasing 486 sequence of "Identification" values for each (src IP, Dst IP) pair. 488 NOTE: 489 F() essentially provides the unpredictability (by off-path 490 attackers) of the resulting "Identification" values, while 491 counter[] provides a linear function such that the 492 "Identification" values are different for each fragmented packet 493 while the "Identification" reuse frequency is minimized. 495 The advantages of this algorithm are: 497 o The "Identification" re-use frequency will typically be lower than 498 that achieved by a global counter (when sending traffic to 499 multiple destinations), since this algorithm uses multiple system- 500 wide counters (rather than a single system-wide counter). The 501 extent to which the re-use frequency will be lower will depend on 502 the number of elements in counter[], and the number of other 503 active flows that result in the same value of G() (and hence cause 504 the same counter to be incremented for each fragmented datagram 505 that is sent). 507 o It is possible to implement the algorithm such that good 508 performance is achieved. For example, the result of F() could be 509 stored in the Destinations Cache (such that it need not be 510 recomputed for each packet that must be sent) along with the 511 computed index/argument for counter[]. 513 NOTE: 514 If this implementation approach is followed, and an entry of 515 the Destinations Cache must be removed as a result of resource 516 management, the last Fragment Identification value used for 517 that Destination will *not* be lost. This is an improvement 518 over the algorithm specified in Section 5.1. 520 The possible drawbacks of this algorithm are: 522 o Since the Fragment Identification values are predictable by the 523 destination host, a vulnerable host could possibly leak to third- 524 parties the Fragment Identification values used by other hosts to 525 send traffic to it (i.e., Host B could leak to Host C the Fragment 526 Identification values that Host A is using to send packets to Host 527 B). Appendix A describes a possible scenario in which that 528 information leakage could take place. We note, however, that this 529 algorithm makes the aforementioned attack less reliable for the 530 attacker, since each counter could be possibly shared by multiple 531 traffic flows (i.e., packets destined to other destinations might 532 cause the same counter to be incremented). 534 This algorithm might be preferable (over the one specified in 535 Section 5.1) in those scenarios in which a node is expected to 536 communicate with a large number of destinations, and thus it is 537 desirable to limit the amount of information to be maintained in 538 memory. 540 NOTE: In such scenarios, if the algorithm specified in Section 5.1 541 were implemented, entries from the Destinations Cache might need 542 to be pruned frequently, thus increasing the risk of Fragment 543 Identification "collisions". 545 6. IANA Considerations 547 There are no IANA registries within this document. The RFC-Editor 548 can remove this section before publication of this document as an 549 RFC. 551 7. Security Considerations 553 This document discusses the security implications of predictable 554 Fragment Identification values, and provides implementation guidance 555 such that the aforementioned security implications can be mitigated. 557 A number of possible algorithms are described, to provide some 558 implementation alternatives to implementers. We note that the 559 selection of such an algorithm usually implies a number of trade-offs 560 (security, performance, implementation complexity, interoperability 561 properties, etc.). 563 8. Acknowledgements 565 The author would like to thank Ivan Arce for proposing the attack 566 scenario described in Appendix A. 568 The author would like to thank Ivan Arce, Stephen Bensley, Ron 569 Bonica, Tassos Chatzithomaoglou, Brian Haberman, Bob Hinden, Sheng 570 Jiang, Tatuya Jinmei, Merike Kaeo, Will Liu, Juan Antonio Matos, 571 Simon Perreault, Hosnieh Rafiee, Meral Shirazipour, Mark Smith, Dave 572 Thaler, and Klaas Wierenga, for providing valuable comments on 573 earlier versions of this document. 575 This document is based on work performed by Fernando Gont on behalf 576 of the UK Centre for the Protection of National Infrastructure 577 (CPNI). 579 9. References 581 9.1. Normative References 583 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 584 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 585 1996, . 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, 589 DOI 10.17487/RFC2119, March 1997, 590 . 592 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 593 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 594 December 1998, . 596 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 597 "Randomness Requirements for Security", BCP 106, RFC 4086, 598 DOI 10.17487/RFC4086, June 2005, 599 . 601 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 602 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 603 DOI 10.17487/RFC4861, September 2007, 604 . 606 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 607 RFC 5722, DOI 10.17487/RFC5722, December 2009, 608 . 610 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 611 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 612 DOI 10.17487/RFC6052, October 2010, 613 . 615 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 616 Protocol Port Randomization", BCP 156, RFC 6056, 617 DOI 10.17487/RFC6056, January 2011, 618 . 620 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 621 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 622 . 624 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", 625 RFC 6946, DOI 10.17487/RFC6946, May 2013, 626 . 628 9.2. Informative References 630 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 631 Errors at High Data Rates", RFC 4963, 632 DOI 10.17487/RFC4963, July 2007, 633 . 635 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 636 DOI 10.17487/RFC5927, July 2010, 637 . 639 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 640 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 641 . 643 [I-D.ietf-6man-deprecate-atomfrag-generation] 644 Gont, F., LIU, S., and T. Anderson, "Deprecating the 645 Generation of IPv6 Atomic Fragments", draft-ietf-6man- 646 deprecate-atomfrag-generation-03 (work in progress), July 647 2015. 649 [Bellovin2002] 650 Bellovin, S., "A Technique for Counting NATted Hosts", 651 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 653 [Fyodor2004] 654 Fyodor, , "Idle scanning and related IP ID games", 2004, 655 . 657 [Herzberg2013] 658 Herzberg, A. and H. Shulman, "Fragmentation Considered 659 Poisonous", Technical Report 13-03, March 2013, 660 . 662 [Klein2007] 663 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 664 Predictable IP ID Vulnerability", 2007, 665 . 668 [Sanfilippo1998a] 669 Sanfilippo, S., "about the ip header id", Post to Bugtraq 670 mailing-list, Mon Dec 14 1998, 671 . 673 [Sanfilippo1998b] 674 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 675 1998, . 677 [Sanfilippo1999] 678 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 679 list, 1999, 680 . 682 [SI6-IPv6] 683 "SI6 Networks' IPv6 toolkit", 684 . 686 [Zalewski2003] 687 Zalewski, M., "A new TCP/IP blind data injection 688 technique?", Post to Bugtraq mailing-list, Thu, 11 Dec 689 2003 00:28:28 +0100 (CET), 2003, 690 . 692 Appendix A. Information leakage produced by vulnerable implementations 694 Section 3 provides a number of references describing a number of ways 695 in which a vulnerable implementation may reveal the Fragment 696 Identification values to be used in subsequent packets, thus opening 697 the door to a number of attacks. In all of those scenarios, a 698 vulnerable implementation leaks/reveals its own Identification 699 number. 701 This section presents a different attack scenario, in which a 702 vulnerable implementation leaks/reveals the Identification number of 703 a non-vulnerable implementation. That is, a vulnerable 704 implementation (Host A) leaks the current Fragment Identification 705 value in use by a third-party host (Host B) to send fragmented 706 datagrams from Host B to Host A. 708 For the most part, this section is included to illustrate how a 709 vulnerable implementation might be leveraged to leak-out the 710 Fragment Identification value of an otherwise non-vulnerable 711 implementation. 713 The following scenarios assume: 715 Host A: 716 An IPv6 host that implements the algorithm specified in 717 Section 5.1, implements [RFC5722], but does not implement 718 [RFC6946]. 720 Host B: 722 Victim node. Selects the Fragment Identification values from a 723 global counter. 725 Host C: 726 Attacker. Can forge the IPv6 Source Address of his packets at 727 will. 729 In the following scenarios, large ICMPv6 Echo Request packets are 730 employed to "sample" the Fragment Identification value of a host. We 731 note that while the figures show only one packet for the ICMPv6 Echo 732 Request and the ICMPv6 Echo Response, each of those packets will 733 typically comprise two fragments, such that the corresponding 734 unfragmented datagram is larger than the MTU of the networks to which 735 Host B and Host C are attached. Additionally, the following 736 scenarios assume that Host A employs a fragment header when sending 737 traffic to Host B (typically the so-called "IPv6 atomic fragments" 738 [RFC6946]): this behavior may be triggered by forged ICMPv6 PTB 739 messages that advertise an MTU smaller than 1280 bytes (assuming the 740 victim does not implement 741 [I-D.ietf-6man-deprecate-atomfrag-generation]). 743 In lines #1-#2 (and lines #8-#9), the attacker samples the current 744 Fragment Identification value at Host B. In line #3, the attacker 745 sends a forged TCP SYN segment to Host A. If corresponding TCP port 746 is closed, and the attacker fails when trying to produce a collision 747 of Fragment Identifications (see line #4), the following packet 748 exchange might take place: 750 A B C 752 #1 <------ Echo Req #1 ----------- 753 #2 --- Echo Resp #1, FID=5000 ---> 754 #3 <------------------- SYN #1, src= B ----------------------- 755 #4 <--- SYN/ACK, FID=42 src=A ---- 756 #5 ---- SYN/ACK, FID=9000 ---> 757 #6 <----- RST, FID= 5001 ----- 758 #7 <----- RST, FID= 5002 ----- 759 #8 <-------- Echo Req #2 --------- 760 #9 --- Echo Resp #2, FID=5003 ---> 762 The two RST segments are elicited by the SYN/ACK segment from line 763 #4, and the (illegitimately elicited by the SYN in line #3) SYN/ACK 764 segment from line #5. 766 On the other hand, if the attacker succeeds to produce a collision of 767 Fragment Identification values, the following packet exchange could 768 take place: 770 A B C 772 #1 <------- Echo Req #1 ---------- 773 #2 --- Echo Resp #1, FID=5000 ---> 774 #3 <------------------- SYN #1, src= B ----------------------- 775 #4 <-- SYN/ACK, FID=9000 src=A --- 776 #5 ---- SYN/ACK, FID=9000 ---> 777 ... (RFC5722) ... 778 #6 <------- Echo Req #2 ---------- 779 #7 ---- Echo Resp #2, FID=5001 --> 781 Clearly, the Fragment Identification value sampled from the second 782 ICMPv6 Echo Response packet ("Echo Resp #2") implicitly indicates 783 whether the Fragment Identification in the forged SYN/ACK (see line 784 #4 in both figures) was the current Fragment Identification in use by 785 Host A. 787 As a result, the attacker could employ this technique to learn the 788 current Fragment Identification value used by host A to send packets 789 to host B, even when Host A itself has a non-vulnerable 790 implementation. 792 Appendix B. Survey of Fragment Identification selection algorithms 793 employed by popular IPv6 implementations 795 This section includes a survey of the Fragment Identification 796 selection algorithms employed in some popular operating systems. 798 The survey was produced with the SI6 Networks' IPv6 toolkit 799 [SI6-IPv6]. 801 +------------------------------+------------------------------------+ 802 | Operating System | Algorithm | 803 +------------------------------+------------------------------------+ 804 | Cisco IOS 15.3 | Predictable (Global Counter, | 805 | | Init=0, Incr=1) | 806 +------------------------------+------------------------------------+ 807 | FreeBSD 9.0 | Unpredictable (Random) | 808 +------------------------------+------------------------------------+ 809 | Linux 3.0.0-15 | Predictable (Global Counter, | 810 | | Init=0, Incr=1) | 811 +------------------------------+------------------------------------+ 812 | Linux-current | Unpredictable (Per-dest Counter, | 813 | | Init=random, Incr=1) | 814 +------------------------------+------------------------------------+ 815 | NetBSD 5.1 | Unpredictable (Random) | 816 +------------------------------+------------------------------------+ 817 | OpenBSD-current | Random (SKIP32) | 818 +------------------------------+------------------------------------+ 819 | Solaris 10 | Predictable (Per-dst Counter, | 820 | | Init=0, Incr=1) | 821 +------------------------------+------------------------------------+ 822 | Windows XP SP2 | Predictable (Global Counter, | 823 | | Init=0, Incr=2) | 824 +------------------------------+------------------------------------+ 825 | Windows XP Professional | Predictable (Global Counter, | 826 | 32bit, SP3 | Init=0, Incr=2) | 827 +------------------------------+------------------------------------+ 828 | Windows Vista (Build 6000) | Predictable (Global Counter, | 829 | | Init=0, Incr=2) | 830 +------------------------------+------------------------------------+ 831 | Windows Vista Business | Predictable (Global Counter, | 832 | 64bit, SP1 | Init=0, Incr=2) | 833 +------------------------------+------------------------------------+ 834 | Windows 7 Home Premium | Predictable (Global Counter, | 835 | | Init=0, Incr=2) | 836 +------------------------------+------------------------------------+ 837 | Windows Server 2003 R2 | Predictable (Global Counter, | 838 | Standard 64bit, SP2 | Init=0, Incr=2) | 839 +------------------------------+------------------------------------+ 840 | Windows Server 2008 Standard | Predictable (Global Counter, | 841 | 32bit, SP1 | Init=0, Incr=2) | 842 +------------------------------+------------------------------------+ 843 | Windows Server 2008 R2 | Predictable (Global Counter, | 844 | Standard 64bit, SP1 | Init=0, Incr=2) | 845 +------------------------------+------------------------------------+ 846 | Windows Server 2012 Standard | Predictable (Global Counter, | 847 | 64bit | Init=0, Incr=2) | 848 +------------------------------+------------------------------------+ 849 | Windows 7 Home Premium | Predictable (Global Counter, | 850 | 32bit, SP1 | Init=0, Incr=2) | 851 +------------------------------+------------------------------------+ 852 | Windows 7 Ultimate 32bit, | Predictable (Global Counter, | 853 | SP1 | Init=0, Incr=2) | 854 +------------------------------+------------------------------------+ 855 | Windows 8 Enterprise 32 bit | Unpredictable (Alg. from Section | 856 | | 5.3) | 857 +------------------------------+------------------------------------+ 859 Table 1: Fragment Identification algorithms employed by different 860 OSes 862 In the text above, "predictable" should be taken as "easily 863 guessable by an off-path attacker, by sending a few probe 864 packets". 866 Author's Address 868 Fernando Gont 869 SI6 Networks / UTN-FRH 870 Evaristo Carriego 2644 871 Haedo, Provincia de Buenos Aires 1706 872 Argentina 874 Phone: +54 11 4650 8472 875 Email: fgont@si6networks.com 876 URI: http://www.si6networks.com