idnits 2.17.1 draft-gont-6man-flowlabel-security-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 12, 2012) is 4399 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) == Unused Reference: 'RFC2119' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'FreeBSD' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'I-D.blake-ipv6-flow-label-nonce' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC6056' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'CPNI-TCP' is defined on line 466, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 3 errors (**), 0 flaws (~~), 8 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 UK CPNI 4 Intended status: BCP March 12, 2012 5 Expires: September 13, 2012 7 Security Assessment of the IPv6 Flow Label 8 draft-gont-6man-flowlabel-security-03 10 Abstract 12 This document discusses the security implications of the IPv6 "Flow 13 Label" header field, and analyzes possible schemes for selecting the 14 Flow Label value of IPv6 packets. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, and it may not be 21 published except as an Internet-Draft. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 13, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Vulnerability analysis . . . . . . . . . . . . . . . . . . . . 4 54 2.1. RFC3697-compliant implementations . . . . . . . . . . . . 4 55 2.1.1. DoS resulting from verification of Flow Label 56 consistency . . . . . . . . . . . . . . . . . . . . . 4 57 2.1.2. Covert channels . . . . . . . . . . . . . . . . . . . 5 58 2.1.3. QoS theft . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1.4. Information Leaking . . . . . . . . . . . . . . . . . 5 60 2.2. RFC6437-compliant implementations . . . . . . . . . . . . 6 61 3. Selecting Flow Label values . . . . . . . . . . . . . . . . . 7 62 3.1. Recommended algorithm . . . . . . . . . . . . . . . . . . 7 63 3.2. Alternative Algorithm . . . . . . . . . . . . . . . . . . 7 64 3.2.1. Secret-key considerations . . . . . . . . . . . . . . 10 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Appendix A. Survey of Flow Label selection algorithms in use 72 by some popular implementations . . . . . . . . . . . 16 73 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 16 78 Appendix B. Changes from previous versions of the draft (to 79 be removed by the RFC Editor before publication 80 of this document as a RFC . . . . . . . . . . . . . . 17 81 B.1. Changes from draft-gont-6man-flowlabel-security-02 . . . . 17 82 B.2. Changes from draft-gont-6man-flowlabel-security-01 . . . . 17 83 B.3. Changes from draft-gont-6man-flowlabel-security-00 . . . . 17 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 The flow label is a 20-bit field that allows a source to label 89 sequences of packets for which it requests special handling by IPv6 90 routers (e.g., non-default quality of service). It is specified in 91 [RFC6437]. RFC 6438 [RFC6438] specifies the use of the Flow Label 92 for Equal Cost Multipath Routing and Link Aggregation in Tunnels. 94 The FLow Label was originally loosely specified in RFC 2460 95 [RFC2460], and then later refined in [RFC3697]. Its specification 96 has been recently revised by RFC 6437 [RFC6437]. [RFC6436] 97 discusses the rationale for the update to the Flow Label 98 specification in [RFC6437]. 100 Section 2Section 2.1[RFC6437]Section 2.2[RFC6437] 102 2. Vulnerability analysis 104 2.1. RFC3697-compliant implementations 106 2.1.1. DoS resulting from verification of Flow Label consistency 108 [RFC2460] states that hosts and routers that do not support the 109 functions of the Flow Label field are required to set this field to 110 zero, pass the field unchanged when forwarding a packet, and ignore 111 the field when forwarding a packet. 113 If any packet belonging to a flow includes a Hop-by-Hop Options 114 header, then all packets of that flow must contain a Hop-by-Hop 115 Options header with the same contents (excluding the Next Header 116 field of the Hop-by-Hop Options header). If any packet belonging to 117 a flow contains a Routing Header, then all packets of that flow must 118 have the same contents in all Extension Headers up to and including 119 the Routing Header (but excluding the Next Header field of the 120 Routing header). 122 Appendix A of [RFC2460] states that routers and destinations are 123 permitted, but not required, to verify that these conditions are 124 satisfied. In order to perform this verification, the Hop-by-Hop 125 Options header (and possibly the Destination Options header and the 126 Routing header) used for the packets of each of the different flows 127 should be kept in memory. This requirement, by itself, would open 128 the door to at least two Denial of Service (DoS) vulnerabilities. 130 Firstly, an attacker could forge a large number of packets with 131 different values for the Flow Label field, thus leading the attacked 132 system to record the Hop-by-Hop Options header (and possibly a 133 Destination Options header and a Routing header) for each of the 134 forged "flows". This might exhaust the attacked system's memory, and 135 thus lead to a system crash or a Denial of Service (DoS) to 136 legitimate flows. 138 If a control protocol is used to convey the special handling for the 139 flow, then such information could be recorded only upon receipt of 140 the first packet belonging to a flow for which this "flow setup" has 141 been completed. And thus this particular threat would be somewhat 142 mitigated. 144 If the nature of the special handling for the flow were carried in a 145 hop-by-hop option, the system performing the aforementioned 146 information would have to record the Hop-by-Hop Options header (and 147 possibly a Destination Options header and a Routing header) of each 148 packet belonging to a "new" flow. As a result, an attacker could 149 simply send a large number of forged packets belonging to different 150 flows, thus leading the attacked system to tie memory for each of 151 these forged flows. This might exhaust the attacked system's memory, 152 and thus lead to a system crash or the Denial of Service (DoS) to 153 legitimate flows. 155 Secondly, rather than aiming at exhausting system resources, an 156 attacker could send forged packets with the intent of having the 157 attacked system record their headers, so that future legitimate 158 packets are discarded as a result of not including the same extension 159 headers that had been recorded upon receipt of the forged packets. 161 Therefore, while this verification might be of help to mitigate some 162 blind attacks by obfuscation, we believe the drawbacks of performing 163 such verification outweigh the potential benefits, and thus recommend 164 systems to not perform such verification. 166 2.1.2. Covert channels 168 As virtually every protocol header field, the Flow Label could be 169 used to implement a covert channel. In those network environments in 170 which the Flow Label is not used, middle-boxes such as packet 171 scrubbers could eliminate this covert channel by resetting the Flow 172 Label with zero, at the expense of disabling the use of the Flow 173 Label for e.g., load-balancing. Such a policy should be carefully 174 evaluated before being enabled, as it would prevent the deployment of 175 any legitimate technology that makes use of the Flow Label field. 177 It should be stress that is very difficult to eliminate all covert 178 channels in a communications protocol, and thus the enforcement of 179 the aforementioned policy should only be applied after careful 180 evaluation. 182 2.1.3. QoS theft 184 If a network identifies flows that will receive a specific QoS by 185 means of the Flow Label, an attacker could forge the packets with 186 specific Flow Label values such that those packets receive that QoS 187 treatment. 189 2.1.4. Information Leaking 191 If a host selects the Flow Label values of outgoing packets such that 192 the resulting sequence of Flow Label values is predictable, this 193 could result in an information leakage. Specifically, if a host sets 194 the Flow Label value of outgoing packets from a system-wide counter, 195 the number of "outgoing flows" would be leaked. This could in turn 196 be used for purposes such as "stealth port scanning" (see Section 3.5 197 of [CPNI-IP]). 199 2.2. RFC6437-compliant implementations 201 The security-wise main changes introduced in [RFC6437] are: 203 o Since Section 6 and Appendix A of RFC 2460 has been essentially 204 obsoleted, the revised specification does not describe any 205 verification for consistency of the Flow Label values of different 206 packets of the same "flow". Therefore, the vulnerability 207 described in Section 2.1.1 has been eliminated. 209 o The revised specification recommends that Flow Label values are 210 not easily predictable, and therefore the vulnerabilities 211 described in Section 2.1.3 and Section 2.1.4 are mitigated. 213 Note: the issue of "covert channels" described in Section 2.1.2 214 remains essentially the same. That is, unless the Flow Label value 215 is rewritten, it may be exploited as a covert channel. However, 216 [RFC6437] mentions this issue, and notes how this could be mitigated 217 in those network scenarios in which covert channels might be a 218 concern. 220 3. Selecting Flow Label values 222 [RFC6437] specifies the requirements for a Flow Label generation 223 algorithm. Essentially: 225 o The Flow Label value must not be easily predictable by a third- 226 party. 228 o Flow Labels (together with the Source Address and the Destination 229 Address) are meant to uniquely identify a packet "flow". Hence, 230 to the extent that is possible each flow should result in a unique 231 {Source Address, Destination Address, Flow Label} set of values at 232 any given time. 234 o In order to help with the use of the Flow Label for Equal Cost 235 Multipath Routing (ECMP) and Link Aggregation (LAG) in Tunnels, 236 Flow Labels should (ideally) have a uniform distribution. 238 Section 3.1 specifies the RECOMMENDED algorithm for selecting Flow 239 Label values. Section 3.2 specifies an alternative algorithm that 240 MAY be used by those implementations concerned about the Flow Label 241 reuse frequency of the RECOMMENDED algorithm. 243 3.1. Recommended algorithm 245 Considering that the Flow Label is a 20-bit field, that Flow Label 246 values must be unique for each (Source Address, Destination Address) 247 pair at any given time, and that [RFC6437] relaxed the requirement of 248 uniqueness that was enforced in [RFC3697], we RECOMMEND that the Flow 249 Label of each flo be selected acording to a PRNG. That is, each Flow 250 Label would be selected with: 252 Flow Label = random() 254 where: 256 random(): 257 Is a a Pseudo-Random Number Generator (PRNG). 259 3.2. Alternative Algorithm 261 Implemenatations concerned with the Flow Label reuse frequency of the 262 algorithm specified in Section 3.1 MAY use the following alternative 263 scheme, which aims at minimizing the Flow Label reuse frequency by 264 producing per-destination monotonically-increasing Flow Label values. 266 Flow Label = F(Source Address, Destination Address, Secret Key2) + 267 table[G(Source Address, Destination Address, Secret Key1)] 269 where: 271 table: 272 Is an array of counters that are initialized to random values upon 273 system bottstrap. The larger the array, the greater the 274 separation of the "increments" space. 276 F(): 277 Is a hash function that should take as input both the Source 278 Address and the Destination Address of the flow, and a secret key. 279 The result of F() should not be computable without knowledge of 280 all the parameters of the hash function. 282 If random numbers are used as the only source of the secret 283 key, they should be chosen in accordance with the 284 recommendations given in [RFC4086]. 286 G(): 287 Is a hash function that should take as input both the Source 288 Address and the Destination Address of the flow, and a secret key. 289 The result of G() should not be computable without knowledge of 290 all the parameters of the hash function. 292 If random numbers are used as the only source of the secret 293 key, they should be chosen in accordance with the 294 recommendations given in [RFC4086]. 296 This scheme should be invoked when a new flow is to be created (e.g., 297 when a new TCP connection is to be created). Once a Flow Label value 298 for such flow is selected, the Flow Label field of all the IPv6 299 packets corresponding to that flow would be set to the selected value 300 (until the flow is terminated). 302 The following figure illustrates this algorithm in pseudo-code: 304 /* Initialization at system boot time */ 305 for(i = 0; i < TABLE_LENGTH; i++) 306 table[i] = random(); 308 /* Flow Label selection function */ 309 offset = F(local_IP, remote_IP, secret_key1); 310 index = G(local_IP, remote_IP, secret_key2); 311 count = 1048576; 313 do { 314 flowlabel = (offset + table[index]) % 1048576; 315 table[index]++; 317 if(three-tuple is unique) 318 return flowlabel; 320 count--; 322 } while (count > 0); 324 /* Set the Flow Label to 0 if there is no 325 unused Flow Label */ 327 return 0; 329 Figure 1 331 The following table shows a sample output of this algorithm: 333 +-----+-------------+-------------+------+----+------+------------+ 334 | Nr. | Src. Addr. | Dst. Addr. | off. | i | t[i] | Flow Label | 335 +-----+-------------+-------------+------+----+------+------------+ 336 | #1 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 5 | 1005 | 337 +-----+-------------+-------------+------+----+------+------------+ 338 | #2 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 6 | 1006 | 339 +-----+-------------+-------------+------+----+------+------------+ 340 | #3 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 10 | 4510 | 341 +-----+-------------+-------------+------+----+------+------------+ 342 | #4 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 11 | 4511 | 343 +-----+-------------+-------------+------+----+------+------------+ 344 | #5 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 7 | 1007 | 345 +-----+-------------+-------------+------+----+------+------------+ 347 Table 1: Sample output of the double-hash algorithm 349 3.2.1. Secret-key considerations 351 Every complex manipulation (like MD5) is no more secure than the 352 input values, and in the case of ephemeral ports, the secret key. If 353 an attacker is aware of which cryptographic hash function is being 354 used by the victim (which we should expect), and the attacker can 355 obtain enough material (e.g. Flow Label values selected by the 356 victim), the attacker may simply search the entire secret key space 357 to find matches. 359 To protect against this, the secret key should be of a reasonable 360 length. Key lengths of 128 bits should be adequate. 362 Another possible mechanism for protecting the secret key is to change 363 it after some time. If the host platform is capable of producing 364 reasonably good random data, the secret key can be changed 365 automatically. 367 Changing the secret will cause abrupt shifts in the selected Flow 368 Label values, and consequently collisions may occur. That is, upon 369 changing the secret, the "offset" value used for each tuple (Source 370 Address, Destination Address) will be different from that computed 371 with the previous secret, thus possibly leading to the selection of a 372 Flow Label value recently used for the same tuple (Source Address, 373 Destination Address). 375 Thus the change in secret key should be done with consideration and 376 could be performed whenever one of the following events occur: 378 o The system is being bootstrapped. 380 o Some predefined/random time has expired. 382 o The secret has been used N times (i.e. we consider it insecure). 384 o There is little traffic (the performance overhead of collisions is 385 tolerated). 387 o There is enough random data available to change the secret key 388 (pseudo-random changes should not be done). 390 4. Security Considerations 392 This document provides a security assessment of the IPv6 Flow Label 393 header field, and possible strategies to mitigate them. 395 5. IANA Considerations 397 There are no IANA registries within this document. The RFC-Editor 398 can remove this section before publication of this document as an 399 RFC. 401 6. Acknowledgements 403 The author would like to thank (in alphabetical order) Shane Amante, 404 Ran Atkinson, Steven Blake, and Brian Carpenter for providing 405 valuable feedback on earlier versions of this document. 407 The offset function used by the algorithm in Section 3.1 was inspired 408 by the mechanism proposed by Steven Bellovin in [RFC1948] for 409 defending against TCP sequence number attacks. 411 This document is heavily based on the document "Security Assessment 412 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] written by 413 Fernando Gont on behalf of the UK Centre for the Protection of 414 National Infrastructure (CPNI). 416 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 417 their continued support. 419 7. References 421 7.1. Normative References 423 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 424 (IPv6) Specification", RFC 2460, December 1998. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 430 "IPv6 Flow Label Specification", RFC 3697, March 2004. 432 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 433 Requirements for Security", BCP 106, RFC 4086, June 2005. 435 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 436 Internet Protocol", RFC 4301, December 2005. 438 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 439 "IPv6 Flow Label Specification", RFC 6437, November 2011. 441 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 442 for Equal Cost Multipath Routing and Link Aggregation in 443 Tunnels", RFC 6438, November 2011. 445 7.2. Informative References 447 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 449 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 450 RFC 1948, May 1996. 452 [I-D.blake-ipv6-flow-label-nonce] 453 Blake, S., "Use of the IPv6 Flow Label as a Transport- 454 Layer Nonce to Defend Against Off-Path Spoofing Attacks", 455 draft-blake-ipv6-flow-label-nonce-02 (work in progress), 456 October 2009. 458 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 459 Protocol Port Randomization", BCP 156, RFC 6056, 460 January 2011. 462 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 463 Update to the IPv6 Flow Label Specification", RFC 6436, 464 November 2011. 466 [CPNI-TCP] 467 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 468 of the Transmission Control Protocol (TCP)", http:// 469 www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf, 470 2009. 472 [CPNI-IP] Gont, F., "Security Assessment of the Internet Protocol", 473 http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008. 475 [CPNI-IPv6] 476 Gont, F., "Security Assessment of the Internet Protocol 477 version 6 (IPv6)", UK Centre for the Protection of 478 National Infrastructure, (available on request). 480 Appendix A. Survey of Flow Label selection algorithms in use by some 481 popular implementations 483 A.1. FreeBSD 485 ? 487 A.2. Linux 489 ? 491 A.3. NetBSD 493 ? 495 A.4. OpenBSD 497 ? 499 A.5. OpenSolaris 501 ? 503 Appendix B. Changes from previous versions of the draft (to be removed 504 by the RFC Editor before publication of this document as a 505 RFC 507 B.1. Changes from draft-gont-6man-flowlabel-security-02 509 o The document now recommends randomized Flow Labels as the default 510 approach, and describes the hash-based approach as an alternative 511 method to be used if there are concerns about the Flow Label reuse 512 frequency. 514 o Minor editorial changes. 516 B.2. Changes from draft-gont-6man-flowlabel-security-01 518 o The document has been updated to contain an analysis of the 519 revised Flow Label specification [RFC6437]. 521 o Minor editorial changes. 523 B.3. Changes from draft-gont-6man-flowlabel-security-00 525 o Clarified *when* Flow Labels are selected, in response to Shane 526 Amante's feedback. 528 Author's Address 530 Fernando Gont 531 UK Centre for the Protection of National Infrastructure 533 Email: fernando@gont.com.ar 534 URI: http://www.cpni.gov.uk