idnits 2.17.1 draft-gont-6man-flowlabel-security-01.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 are 2 instances of too long lines in the document, the longest one being 4 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 (November 17, 2010) is 4906 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) == Missing Reference: 'RFC 3697' is mentioned on line 193, but not defined ** Obsolete undefined reference: RFC 3697 (Obsoleted by RFC 6437) == Unused Reference: 'RFC2119' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'FreeBSD' is defined on line 515, 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: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group F. Gont 3 (6man) UK CPNI 4 Internet-Draft November 17, 2010 5 Intended status: BCP 6 Expires: May 21, 2011 8 Security Assessment of the IPv6 Flow Label 9 draft-gont-6man-flowlabel-security-01 11 Abstract 13 This document discusses the security implications of the IPv6 "Flow 14 Label" header field, and analyzes possible schemes for selecting the 15 Flow Label value of IPv6 packets. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be modified, 21 and derivative works of it may not be created, and it may not be 22 published except as an Internet-Draft. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 21, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Threat analysis . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. DoS resulting from verification of Flow Label 56 consistency . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Covert channels . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. QoS theft . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. Information Leaking . . . . . . . . . . . . . . . . . . . 5 60 3. Selecting Flow Label values . . . . . . . . . . . . . . . . . 6 61 4. Secret-key considerations . . . . . . . . . . . . . . . . . . 12 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 68 Appendix A. Survey of Flow Label selection algorithms in use 69 by some popular implementations . . . . . . . . . . . 18 70 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 18 75 Appendix B. Changes from previous versions of the draft (to 76 be removed by the RFC Editor before publication 77 of this document as a RFC . . . . . . . . . . . . . . 19 78 B.1. Changes from draft-gont-6man-flowlabel-security-00 . . . . 19 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 1. Introduction 83 The flow label is a 20-bit field that allows a source to label 84 sequences of packets for which it requests special handling by IPv6 85 routers (e.g., non-default quality of service). It was loosely 86 specified in RFC 2460 [Deering and Hinden, 1998] and its 87 specification was later refined in [RFC3697]. 89 While the Flow Label could be used for e.g., load-sharing 90 purposes, the author is not aware of any deployed use cases. 92 2. Threat analysis 94 2.1. DoS resulting from verification of Flow Label consistency 96 [RFC2460] states that hosts and routers that do not support the 97 functions of the Flow Label field are required to set this field to 98 zero, pass the field unchanged when forwarding a packet, and ignore 99 the field when forwarding a packet. 101 If any packet belonging to a flow includes a Hop-by-Hop Options 102 header, then they all must be sent with the same Hop-by-Hop Options 103 header contents (excluding the Next Header field of the Hop-by-Hop 104 Options header). If any of those packets contains a Routing Header, 105 then all packets belonging to that flow must be originated with the 106 same contents in all Extension Headers up to and including the 107 Routing Header (but excluding the Next Header field of the Routing 108 header). 110 Appendix A of [RFC2460] states that routers and destinations are 111 permitted, but not required, to verify that these conditions are 112 satisfied. In order to perform this verification, the Hop-by-Hop 113 Options header (and possibly the Destination Options header and the 114 Routing header) used for the packets of each of the different flows 115 should be kept in memory. This requirement, by itself, would open 116 the door to at least two Denial of Service (DoS) vulnerabilities. 118 Firstly, an attacker could forge a large number of packets with 119 different values for the Flow Label field, thus leading the attacked 120 system to record the Hop-by-Hop Options header (and possibly a 121 Destination Options header and a Routing header) for each of the 122 forged "flows". This might exhaust the attacked system's memory, and 123 thus lead to a system crash or a Denial of Service (DoS) to 124 legitimate flows. 126 If a control protocol is used to convey the special handling for the 127 flow, then such information could be recorded only upon receipt of 128 the first packet belonging to a flow for which this "flow setup" has 129 been completed. And thus this particular threat would be somewhat 130 mitigated. 132 If the nature of the special handling for the flow were carried in a 133 hop-by-hop option, the system performing the aforementioned 134 information would have to record the Hop-by-Hop Options header (and 135 possibly a Destination Options header and a Routing header) of each 136 packet belonging to a "new" flow. As a result, an attacker could 137 simply send a large number of forged packets belonging to different 138 flows, thus leading the attacked system to tie memory for each of 139 these forged flows. This might exhaust the attacked system's memory, 140 and thus lead to a system crash or the Denial of Service (DoS) to 141 legitimate flows. 143 Secondly, rather than aiming at exhausting system resources, an 144 attacker could send forged packets with the intent of having the 145 attacked system record their headers, so that future legitimate 146 packets are discarded as a result of not including the same extension 147 headers that had been recorded upon receipt of the forged packets. 149 Therefore, while this verification might be of help to mitigate some 150 blind attacks by obfuscation, we believe the drawbacks of performing 151 such verification outweigh the potential benefits, and thus recommend 152 systems to not perform such verification. 154 2.2. Covert channels 156 As virtually every protocol header field, the Flow Label could be 157 used to implement a covert channel. In those network environments in 158 which the Flow Label is not used, middle-boxes such as packet 159 scrubbers could eliminate this covert channel by resetting the Flow 160 Label with zero, at the expense of disabling the use of the Flow 161 Label for e.g., load-balancing. Such a policy should be carefully 162 evaluated before being enabled, as it would prevent the deployment of 163 any legitimate technology that makes use of the Flow Label field. 165 It should be stress that is very difficult to eliminate all covert 166 channels in a communications protocol, and thus the enforcement of 167 the aforementioned policy should only be applied after careful 168 evaluation. 170 2.3. QoS theft 172 If a network identifies flows that will receive a specific QoS by 173 means of the Flow Label, an attacker could forge the packets with 174 specific Flow Label values such that those packets receive that QoS 175 treatment. 177 2.4. Information Leaking 179 If a host selects the Flow Label values of outgoing packets such that 180 the resulting sequence of Flow Label values is predictable, this 181 could result in an information leakeage. Specifically, if a host 182 sets the Flow Label value of outgoing packets from a system-wide 183 counter, the number of "outgoing flows" would be leaked. This could 184 in turn be used for purposes such as "stealth port scanning" (see 185 Section 3.5 of [CPNI-IP]). 187 3. Selecting Flow Label values 189 [RFC3697] specifies how the Flow Label should be used by the 190 processing nodes. It states that "source nodes SHOULD assign each 191 unrelated transport connection and application data stream to a new 192 flow". It recommends the following requirements for the assignment 193 policy [RFC 3697]: 195 o A source node MUST ensure that it does not unintentionally reuse 196 Flow Label values it is currently using or has recently used when 197 creating new flows. Flow Label values previously used with a 198 specific pair of source and destination addresses MUST NOT be 199 assigned to new flows with the same address pair within 120 200 seconds of the termination of the previous flow. 202 o The source node SHOULD provide the means for the applications and 203 transport protocols to specify quarantine periods longer than the 204 default 120 seconds for individual flows. 206 o To avoid accidental Flow Label value reuse, the source node SHOULD 207 select new Flow Label values in a well-defined sequence (e.g., 208 sequential or pseudo-random) and use an initial value that avoids 209 reuse of recently used Flow Label values each time the system 210 restarts. The initial value SHOULD be derived from a previous 211 value stored in non-volatile memory, or in the absence of such 212 history, a randomly generated initial value using techniques that 213 produce good randomness properties SHOULD be used. 215 These requirements are very similar to those of TCP port numbers, 216 TCP Initial Sequence Numbers, and TCP timestamps. [CPNI-TCP] 217 provides a detailed discussion of the requirements for such TCP 218 parameters, and a number of algorithms that could be used to meet 219 those requirements. 221 A simple strategy for selecting Flow Label values such that they are 222 not reused too quickly would be to select them according to a global 223 counter. However, if such a scheme were used, it could possibly be 224 exploited in a similar way to that in which predictable IPv4 225 Identification values can be exploited (see Section 3.5 of 226 [CPNI-TCP]). Therefore, the Flow Label should be obfuscated so that 227 the chances of an off-path attacker of guessing the Flow Label of 228 future flows are reduced. 230 Considering that the Flow Label is a 20-bit field, and that Flow 231 Label values must be unique for each (Source Address, Destination 232 Address) pair at any given time, it might make sense to simply 233 randomize the Flow Label value for each new flow. 235 This has been proposed in [I-D.blake-ipv6-flow-label-nonce]. 237 In order to reduce the chances of collisions of Flow Label values, 238 while still providing obfuscation, we propose that the Flow Label for 239 new IPv6 flows be selected according the following scheme: 241 Flow Label = counter + F(Source Address, Destination Address, Secret Key) 243 where: 245 counter: 246 Is a variable that is initialized to some arbitrary value, and is 247 incremented once for each flow label value that is selected. 249 F(): 250 Is a hash function that should take as input both the Source 251 Address and the Destination Address, and a secret key. The result 252 of F should not be computable without the knowledge of all the 253 parameters of the hash function. 255 This scheme should be used when a new flow is to be created (e.g., 256 when a new TCP connection is to be created). Once a Flow Label value 257 for such flow is selected, the Flow Label field of all the IPv6 258 packets corresponding to that flow would be set to the selected value 259 (until the flow is terminated). 261 This scheme was originally proposed in [RFC1948] for the selection of 262 TCP Initial Sequence Numbers, and later proposed for the selection of 263 TCP ephemeral ports [I-D.ietf-tsvwg-port-randomization] and for the 264 selection of TCP timestamps [CPNI-TCP]. 266 This scheme separates the Flow Label space for each pair of (Source 267 Address, Destination Address), resulting in a sequence of 268 monotonically-increasing Flow Label values (with a pseudo-random 269 origin) within each of those Flow Label spaces. 271 The following figure illustrates this algorithm in pseudo-code: 273 /* Initialization at system boot time */ 274 counter = 0; 276 /* Flow Label selection function */ 277 offset = F(local_IP, remote_IP, secret_key); 279 count = 1048576; 281 do { 282 flowlabel = (offset + counter) % 1048576; 283 counter++; 285 if(three-tuple is unique) 286 return flowlabel; 288 count--; 290 } while (count > 0); 292 /* Set the Flow Label to 0 if there is no 293 unused Flow Label */ 295 return 0; 297 Figure 1 299 This algorithm should be executed when a new flow is to be created 300 (e.g., when a new TCP connection is to be created). Once a Flow 301 Label value for such flow is selected, the Flow Label field of all 302 the IPv6 packets corresponding to that flow would be set to the 303 selected value (until the flow is terminated). 305 The following table shows a sample output of this scheme: 307 +-----+-------------+-------------+--------+---------+------------+ 308 | Nr. | Src. Addr. | Dst. Addr. | offset | counter | Flow Label | 309 +-----+-------------+-------------+--------+---------+------------+ 310 | #1 | 2001:db8::1 | 2001:db8::2 | 1000 | 0 | 1000 | 311 +-----+-------------+-------------+--------+---------+------------+ 312 | #2 | 2001:db8::1 | 2001:db8::2 | 1000 | 1 | 1001 | 313 +-----+-------------+-------------+--------+---------+------------+ 314 | #3 | 2001:db8::1 | 2001:db8::4 | 4500 | 2 | 4502 | 315 +-----+-------------+-------------+--------+---------+------------+ 316 | #4 | 2001:db8::1 | 2001:db8::4 | 4500 | 3 | 4503 | 317 +-----+-------------+-------------+--------+---------+------------+ 318 | #5 | 2001:db8::1 | 2001:db8::2 | 1000 | 4 | 1004 | 319 +-----+-------------+-------------+--------+---------+------------+ 321 Table 1: Sample output of the simple-hash algorithm 323 This scheme can be further improved by separating the increment 324 spaces, such that the selection of a Flow Label within one space does 325 not necessarily cause a Flow Label value to be skipped in the other 326 spaces. To perform a separation of the increment spaces, the global 327 counter would be replaced with an array of counters as follows: 329 Flow Label = table[G(Source Address, Destination Address, Secret Key1)] + 330 F(Source Address, Destination Address, Secret Key2) 332 where: 334 table: 335 Is an array of counters that are initialized to some arbitrary 336 value. The larger the array, the greater the obfuscation. 338 F(): 339 Is a hash function that should take as input both the Source 340 Address and the Destination Address, and a secret key. The result 341 of F should not be computable without the knowledge of all the 342 parameters of the hash function. 344 G(): 345 Is a hash function that should take as input both the Source 346 Address and the Destination Address, and a secret key. The result 347 of F should not be computable without the knowledge of all the 348 parameters of the hash function. 350 As with the previous algorithm, this scheme should be invoked when a 351 new flow is to be created (e.g., when a new TCP connection is to be 352 created). Once a Flow Label value for such flow is selected, the 353 Flow Label field of all the IPv6 packets corresponding to that flow 354 would be set to the selected value (until the flow is terminated). 356 The following figure illustrates this algorithm in pseudo-code: 358 /* Initialization at system boot time */ 359 for(i = 0; i < TABLE_LENGTH; i++) 360 table[i] = random(); 362 /* Flow Label selection function */ 363 offset = F(local_IP, remote_IP, secret_key1); 364 index = G(local_IP, remote_IP, secret_key2); 365 count = 1048576; 367 do { 368 flowlabel = (offset + table[index]) % 1048576; 369 table[index]++; 371 if(three-tuple is unique) 372 return flowlabel; 374 count--; 376 } while (count > 0); 378 /* Set the Flow Label to 0 if there is no 379 unused Flow Label */ 381 return 0; 383 Figure 2 385 This scheme does not strictly comply with the requirement that a Flow 386 Label value must not be reassigned assigned to new flows with the 387 same address pair within 120 seconds of the termination of the 388 previous flow. However, by minimizing the Flow Label reuse 389 frequency, it is expected that in virtually all real network 390 scenarios such a requirement will be met. 392 The following table shows a sample output of this algorithm: 394 +-----+-------------+-------------+------+----+------+------------+ 395 | Nr. | Src. Addr. | Dst. Addr. | off. | i | t[i] | Flow Label | 396 +-----+-------------+-------------+------+----+------+------------+ 397 | #1 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 5 | 1005 | 398 +-----+-------------+-------------+------+----+------+------------+ 399 | #2 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 6 | 1006 | 400 +-----+-------------+-------------+------+----+------+------------+ 401 | #3 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 10 | 4510 | 402 +-----+-------------+-------------+------+----+------+------------+ 403 | #4 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 11 | 4511 | 404 +-----+-------------+-------------+------+----+------+------------+ 405 | #5 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 7 | 1007 | 406 +-----+-------------+-------------+------+----+------+------------+ 408 Table 2: Sample output of the double-hash algorithm 410 We recommend the implementation of this algorithm for the selection 411 of the Flow Label. 413 4. Secret-key considerations 415 Every complex manipulation (like MD5) is no more secure than the 416 input values, and in the case of ephemeral ports, the secret key. If 417 an attacker is aware of which cryptographic hash function is being 418 used by the victim (which we should expect), and the attacker can 419 obtain enough material (e.g. Flow Label values selected by the 420 victim), the attacker may simply search the entire secret key space 421 to find matches. 423 To protect against this, the secret key should be of a reasonable 424 length. Key lengths of 128 bits should be adequate. 426 Another possible mechanism for protecting the secret key is to change 427 it after some time. If the host platform is capable of producing 428 reasonably good random data, the secret key can be changed 429 automatically. 431 Changing the secret will cause abrupt shifts in the selected Flow 432 Label values, and consequently collisions may occur. That is, upon 433 changing the secret, the "offset" value used for each tuple (Source 434 Address, Destination Address) will be different from that computed 435 with the previous secret, thus possibly leading to the selection of a 436 Flow Label value recently used for the same tuple (Source Address, 437 Destination Address). 439 Thus the change in secret key should be done with consideration and 440 could be performed whenever one of the following events occur: 442 o The system is being bootstrapped. 444 o Some predefined/random time has expired. 446 o The secret has been used N times (i.e. we consider it insecure). 448 o There is little traffic (the performance overhead of collisions is 449 tolerated). 451 o There is enough random data available to change the secret key 452 (pseudo-random changes should not be done). 454 5. Security Considerations 456 This document provides a security assessment of the IPv6 FLow Label 457 header field, and possible strategies to mitigate these threats. 459 This document proposes an algorithm for selecting the Flow Label 460 values at hosts that complies with the current specification of the 461 the Flow Label field, such that some threats are mitigated. 463 If the local offset function F() results in identical offsets for 464 different inputs at greater frequency than would be expected by 465 chance, the port-offset mechanism proposed in this document would 466 have a reduced effect. 468 If random numbers are used as the only source of the secret key, they 469 should be chosen in accordance with the recommendations given in 470 [RFC4086]. 472 6. IANA Considerations 474 There are no IANA registries within this document. The RFC-Editor 475 can remove this section before publication of this document as an 476 RFC. 478 7. Acknowledgements 480 This document is heavily based on the upcoming document "Security 481 Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6]. 483 The author would like to thank (in alphabetical order) Shane Amante 484 and Brian Carpenter for providing valuable feedback on earlier 485 versions of this document. 487 The offset function used in this document was inspired by the 488 mechanism proposed by Steven Bellovin in [RFC1948] for defending 489 against TCP sequence number attacks. 491 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 492 their continued support. 494 8. References 496 8.1. Normative References 498 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 499 (IPv6) Specification", RFC 2460, December 1998. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 505 "IPv6 Flow Label Specification", RFC 3697, March 2004. 507 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 508 Requirements for Security", BCP 106, RFC 4086, June 2005. 510 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 511 Internet Protocol", RFC 4301, December 2005. 513 8.2. Informative References 515 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 517 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 518 RFC 1948, May 1996. 520 [I-D.blake-ipv6-flow-label-nonce] 521 Blake, S., "Use of the IPv6 Flow Label as a Transport- 522 Layer Nonce to Defend Against Off-Path Spoofing Attacks", 523 draft-blake-ipv6-flow-label-nonce-02 (work in progress), 524 October 2009. 526 [I-D.ietf-tsvwg-port-randomization] 527 Larsen, M. and F. Gont, "Transport Protocol Port 528 Randomization Recommendations", 529 draft-ietf-tsvwg-port-randomization-09 (work in progress), 530 August 2010. 532 [CPNI-TCP] 533 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 534 of the Transmission Control Protocol (TCP)", http:// 535 www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf, 536 2009. 538 [CPNI-IP] Gont, F., "Security Assessment of the Internet Protocol", 539 http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008. 541 [CPNI-IPv6] 542 Gont, F., "Security Assessment of the Internet Protocol 543 version 6 (IPv6)", UK Centre for the Protection of 544 National Infrastructure, (to be published). 546 Appendix A. Survey of Flow Label selection algorithms in use by some 547 popular implementations 549 A.1. FreeBSD 551 ? 553 A.2. Linux 555 ? 557 A.3. NetBSD 559 ? 561 A.4. OpenBSD 563 ? 565 A.5. OpenSolaris 567 ? 569 Appendix B. Changes from previous versions of the draft (to be removed 570 by the RFC Editor before publication of this document as a 571 RFC 573 B.1. Changes from draft-gont-6man-flowlabel-security-00 575 o Clarified *when* Flow Labels are selected, in response to Shane 576 Amante's feedback. 578 Author's Address 580 Fernando Gont 581 UK Centre for the Protection of National Infrastructure 583 Email: fernando@gont.com.ar