idnits 2.17.1 draft-blake-ipv6-flow-label-nonce-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-03 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-10 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-02 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-01 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-intro-02 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Blake 3 Internet-Draft Extreme Networks 4 Intended status: Standards Track October 26, 2009 5 Expires: April 29, 2010 7 Use of the IPv6 Flow Label as a Transport-Layer Nonce 8 to Defend Against Off-Path Spoofing Attacks 9 draft-blake-ipv6-flow-label-nonce-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 29, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 TCP and other transport-layer protocols are vulnerable to spoofing 58 attacks from off-path hosts. These attacks can be prevented through 59 the use of cryptographic authentication. However, it is difficult to 60 use cryptographic authentication in all circumstances. A variety of 61 obfuscation techniques -- such as initial sequence number 62 randomization and source port randomization -- increase the effort 63 required of an attacker to successfully guess the packet header 64 fields which uniquely identify a transport connection. This memo 65 proposes the use of the IPv6 Flow Label field as a random, per- 66 connection nonce value, to add entropy to the set of packet header 67 fields used to identify a transport connection. This mechanism is 68 easily implementable, allows for incremental deployment, and is fully 69 compliant with the rules for Flow Label use defined in RFC 3697. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. TCP's Vulnerability to Blind Spoofing Attacks . . . . . . 4 75 1.2. IPv6 Flow Label . . . . . . . . . . . . . . . . . . . . . 5 76 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 77 3. Additional Requirements on Flow Label Value Generation and 78 Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4. TCP Considerations . . . . . . . . . . . . . . . . . . . . . . 9 80 5. UDP Considerations . . . . . . . . . . . . . . . . . . . . . . 11 81 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 7. DCCP Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . . 12 84 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 12 85 10. Support for Transport Connection Sub-Flows . . . . . . . . . . 13 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 14.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 1.1. TCP's Vulnerability to Blind Spoofing Attacks 98 Recent effort has been directed towards identifying and reducing the 99 vulnerability of TCP [RFC0793] to a variety of "blind" spoofed packet 100 injection attacks from hosts that are off-path (i.e., not able to 101 intercept communications between a pair of hosts) [RFC4953][RFC5082] 102 [I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-tcpsecure] 103 [I-D.ietf-tsvwg-port-randomization]. Off-path spoofing attacks 104 against TCP require an attacker to correctly guess the 4-tuple of 105 header fields uniquely identifying a TCP connection, 107 along with a valid (in-receive window) value for the 32-bit TCP 108 sequence number. By correctly guessing values for these fields, an 109 attacker is then able to inject ACK, DATA, RST, or SYN segments into 110 a TCP connection, enabling throughput reduction, data corruption, or 111 connection termination with a single correctly constructed packet. 112 Similarly, by correctly guessing values for these fields, an attacker 113 is able to forge ICMP messages to a host, with similar negative 114 consequences [I-D.ietf-tcpm-icmp-attacks]. 116 Increased use of long-duration connections by applications, as well 117 as faster access link speeds, increase the ability of attackers to 118 transmit a sufficient number of spoof packets to successfully attack 119 a connection, especially when either the destination or source ports 120 are easily guessable. Cryptographic authentication mechanisms such 121 as the TCP MD5 Authentication Option [RFC2385], TCP Authentication 122 Option [I-D.ietf-tcpm-tcp-auth-opt], and IPsec [RFC4301] can secure 123 against these attacks, as well as some on-path (man-in-the-middle) 124 attacks. However, key management and computational overhead makes 125 the deployment of cryptographic authentication prohibitively 126 expensive in some environments and for some applications. 128 Network ingress filtering of IP source addresses has been widely 129 deployed at network boundaries, significantly reducing the set of 130 networks that a particular host can inject spoof packets into 131 [RFC2827][RFC3704]. But network ingress filtering is not universally 132 deployed, leaving many networks vulnerable to spoofed packet attacks 133 (including the attacker's network). Note also that network ingress 134 filtering typically provides no protection against ICMP spoofing 135 attacks, since the attacker does not need to spoof the IP source 136 address in the ICMP packet header (only the IP destination address in 137 the ICMP message payload). 139 Obfuscation techniques can be employed to increase the effort 140 required of an attacker. Initial sequence number randomization 141 [RFC1948] [I-D.ietf-tcpm-tcpsecure] can be implemented by both the 142 client (the host initiating a connection) and server. For typical 143 window sizes of approximately 32 Kbytes, this technique forces an 144 attacker to send approximately 57000 RST packets on average to reset 145 a connection [RFC4953]. Source port randomization 146 [I-D.ietf-tsvwg-port-randomization] can also be implemented by a 147 client to increase the number of guesses an attacker must make to 148 successfully attack a connection. This mechanism can provide an 149 additional ~15 bits of entropy (depending on implementation). Source 150 port randomization can also be used with other transport protocols. 152 Both obfuscation schemes are compliant with [RFC0793], and are 153 incrementally deployable. Both schemes used in combination introduce 154 approximately 32 bits of entropy (~17 + ~15) with typical window 155 sizes in use today. However, as access link speeds (and 156 consequently, receive windows) increase in size, the amount of 157 entropy declines just as the number of spoof packets an attacker can 158 generate in a given interval increases. Therefore, the margin of 159 protection provided by these obfuscation mechanisms will decrease 160 over time. 162 1.2. IPv6 Flow Label 164 IPv6 [RFC2460] includes a 20-bit Flow Label field, which can be used 165 by hosts to uniquely label a uni-directional sequence of packets from 166 a host to a particular unicast, anycast, or multicast destination. 167 The tuple of 168 is intended to uniquely identify a particular flow during its 169 lifetime (plus a subsequent quarantine period). Rules for the 170 generation and usage of Flow Label values are defined in [RFC3697]. 171 Because transport-layer port fields may be located at a variable 172 offset within a packet due to IPv6 extension headers, or may be 173 obscured due to encryption, the Flow Label provides a fixed field in 174 the IPv6 header to facilitate flow classification in routers. 176 While originally intended to facilitate flow-specific packet handling 177 in routers (e.g., QoS, fast switching), the Flow Label can also be 178 used by hosts to uniquely label one or more transport connections. 179 An originating host may select a random Flow Label value at the 180 beginning of a connection, and continue to use it for the 181 connection's duration. The host (or hosts for multicast) at the 182 other end of the connection can record this Flow Label value, and use 183 it as part of the connection demultiplexing key, while also labeling 184 response packets with the same or a different Flow Label value. The 185 originating host can similarly record the Flow Label value in 186 response packets, and use it as part of its connection demultiplexing 187 key. In this way an additional 20 bits of entropy is added to the 188 set of header fields used to identify a transport connection. When 189 used in addition to source port randomization, the total amount of 190 entropy is approximately 34-35 bits. When TCP initial sequence 191 number randomization is also used (i.e., in TCP), the entropy is 192 increased to > 40 bits (even for large windows), making off-path 193 snooping attacks impractical. 195 The Flow Label field is not included in the pseudo header checksum of 196 any of the standard transport protocols. Corruption of the Flow 197 Label value (that is not detected by any link-layer checksum) will be 198 interpreted by the receiving host as evidence of an attack (rather 199 than otherwise being ignored). The recommended response by the 200 receiving host (to silently discard the packet) is the same as in the 201 case of a packet with a checksum error. 203 The concept of labeling transport connections to prevent off-path 204 spoofing attacks was proposed in [McGann05], in the context of 205 stateful firewalls. This scheme may be useful for other transport 206 protocols such as SCTP [RFC4960], UDP [RFC0768], UDP-Lite [RFC3828], 207 DCCP [RFC4340], and RTP [RFC3550]. Host implementations in 208 compliance with [RFC3697] which do not allocate multiple flows to a 209 single transport connection will either label all packets in the 210 connection with a Flow Label value of 0, or with some other constant. 211 Therefore, this scheme is incrementally deployable by either peer in 212 a connection. By introducing an incentive for hosts to begin 213 utilizing the Flow Label, its utility for other network applications 214 (e.g., as part of the ECMP load balancing key in routers) is 215 improved. 217 Section 3 specifies additional requirements on Flow Label generation. 218 Section 4 describes the use of this scheme with TCP. Section 5 219 describes the use of this scheme with UDP and UDP-Lite. Section 6 220 describes the use of this scheme with SCTP. Section 7 describes the 221 use of this scheme with DCCP. Section 8 describes the use of this 222 scheme with RTP over UDP or DCCP. Section 9 describes the 223 implications of IPv6 network address translation with respect to this 224 scheme. Section 10 describes an alternative receiver behavior which 225 allows support for multiple sub-flows within a transport connection. 227 2. Requirements Language 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [RFC2119]. 233 3. Additional Requirements on Flow Label Value Generation and Use 235 [RFC3697] specifies the rules governing use of the IPv6 Flow Label. 237 The primary requirements relevant to our purpose are as follows 238 (quoting directly): 240 o A Flow Label of zero is used to indicate packets not part of any 241 flow. 243 o The Flow Label value set by the source MUST be delivered unchanged 244 to the destination node(s). 246 o To enable Flow Label based classification, source nodes SHOULD 247 assign each unrelated transport connection and application data 248 stream to a new flow. 250 o The source node SHOULD be able to select unused Flow Label values 251 for flows not requesting a specific value to be used. 253 o A source node MUST ensure that it does not unintentionally reuse 254 Flow Label values it is currently using or has recently used when 255 creating new flows. 257 o Flow Label values previously used with a specific pair of source 258 and destination addresses MUST NOT be assigned to new flows with 259 the same address pair within 120 seconds of the termination of the 260 previous flow. 262 o The source node SHOULD provide the means for the applications and 263 transport protocols to specify quarantine periods longer than the 264 default 120 seconds for individual flows. 266 o To avoid accidental Flow Label value reuse, the source node SHOULD 267 select the new Flow Label value in a well-defined sequence, (e.g., 268 sequential or pseudo-random) and use an initial value that avoids 269 reuse of recently used Flow Label values each time the system 270 restarts. The initial value SHOULD be derived from a previous 271 value stored in non-volatile memory, or in the absence of such 272 history, a randomly generated initial value using techniques that 273 produce good randomness properties SHOULD be used. 275 We wish to use the Flow Label value as an unguessable nonce. Hence, 276 the following additional requirements are implied: 278 o Source hosts MUST assign each unrelated transport connection and 279 application data stream to a new flow (i.e., with a non-zero Flow 280 Label value). 282 o Source hosts MUST be able to select unused Flow Label values for 283 flows not requesting a specific value to be used. The selected 284 Flow Label value must remain constant for the duration of the 285 flow. 287 o The Flow Label value MUST be practically unguessable, in a manner 288 similar to the TCP source port or initial sequence number when 289 they are randomized. A random number generator with good 290 randomness properties (i.e., uniformly distributed) as specified 291 in [RFC4086] MUST be used to generate Flow Label values not 292 explicitly requested by an application. 294 o Flow Label state for a transport connection or application data 295 stream MUST be cleaned-up by hosts as part of the transport 296 connection/application data stream state clean-up. 298 o Flow Label values previously used with a specific pair of source 299 and destination addresses MUST NOT be assigned to new flows with 300 the same address pair within X seconds of the termination of the 301 previous flow, where X is the maximum of either 120 seconds, or 302 the duration for which transport connection state might linger at 303 a host after traffic flow has ceased (e.g., TIME-WAIT state in 304 TCP). 306 We assume that the requirement of [RFC3697] that "The Flow Label 307 value set by the source MUST be delivered unchanged to the 308 destination node(s)" applies also when the Flow Label value is 0. By 309 implication we assume that intermediate nodes are not allowed to 310 assign a packet to a flow, whether or not the source node did so. 312 For this particular application of the Flow Label field, no problem 313 would be posed if multiple flows from a source host in unrelated 314 transport connections/application data streams coincidentally shared 315 the same Flow Label value, as long as the other previous requirements 316 are adhered to. However, the prohibition in [RFC3697] against 317 simultaneous reuse of Flow Label values MUST be observed. Any 318 application request to assign a specific Flow Label value already in 319 use by another flow MUST be rejected. 321 Transport-specific requirements on Flow Label use are provided in the 322 subsequent sections. However, as a general requirement, if a packet 323 is received on a transport connection/application data stream with an 324 unexpected Flow Label value, the packet MUST be silently discarded. 325 If excessive Flow Label errors are received, this event SHOULD be 326 logged. 328 ICMPv6 error messages contain the IPv6 header of the packet 329 triggering the error [RFC4443]. A host receiving an ICMPv6 error 330 message can validate the Flow Label value in the message payload to 331 protect against ICMPv6 spoofing attacks [I-D.ietf-tcpm-icmp-attacks]. 333 Use of the Flow Label value as an unguessable nonce is incrementally 334 deployable, whether a source host fails to support setting the Flow 335 Label to a non-zero value, or a destination host fails to check its 336 value. However, a Flow Label value of 0 is easily guessable, so 337 resistance to spoofing attacks is not improved. Hosts SHOULD NOT 338 rely on the mechanisms defined in this document when operating in 339 high-threat environments. 341 The additional requirements given here for Flow Label generation and 342 use are not in conflict with the requirements in [RFC3697]. 343 Therefore, additional applications of the Flow Label field (e.g., for 344 special QoS handling, load balancing, etc.) can be applied 345 simultaneously with the use of the Flow Label field as a transport- 346 layer nonce, so long as an additional application does not limit the 347 permissible values of the Flow Label in any way which violates the 348 requirement that the value be unpredictable. 350 4. TCP Considerations 352 Uni-directional traffic in a TCP connection is assumed to constitute 353 a single flow, and hence MUST be assigned a unique Flow Label value 354 by the source host; either explicitly by the application or 355 automatically by the host's TCP/IP stack. Given the Flow Label 356 value's additional use as a packet classification field in routers 357 (for QoS or other purposes), there is no compelling reason to sub- 358 divide traffic within a TCP connection into multiple flows for 359 classification purposes. 361 For this application of the Flow Label field, it would not pose a 362 problem if multiple TCP connections from a source host (whether to 363 one or a multiple of destination hosts) reused the same Flow Label 364 value. However, because of the additional uses of the Flow Label 365 field, a host MUST NOT assign the same Flow Label value to multiple 366 TCP connections. Both directions of traffic flow in a TCP connection 367 are not required to share the same Flow Label value, nor are they 368 prohibited from doing so. 370 A host originating a TCP connection (client) selects a unique Flow 371 Label value for the connection, which it stores as the 372 OUTGOING_FLOW_ID in its Transport Control Block (TCB) for this 373 connection. The Flow Label selection algorithm can run 374 simultaneously with TCP source port and initial sequence number 375 selection (e.g., by generating a single random variable and assigning 376 bit-ranges within it to each field). This Flow Label value is 377 included in the first (and subsequent) SYN packet(s) sent to the 378 destination host (server). The server receiving the first SYN packet 379 records the Flow Label value in its TCB for this connection as the 380 INCOMING_FLOW_ID. The server then selects a unique Flow Label value 381 for the connection, which it stores as the OUTGOING_FLOW_ID in the 382 connection's TCB. It includes this Flow Label value in the first 383 (and subsequent) SYN-ACK packet(s) sent to the client. The client 384 receiving the SYN-ACK packet from the server records the Flow Label 385 value in its TCB for this connection as the INCOMING_FLOW_ID. It 386 sends all additional packets of the connection to the server using 387 OUTGOING_FLOW_ID, and checks all incoming packets of the connection 388 from the server to ensure that they include INCOMING_FLOW_ID. The 389 server performs identical processing. Any packets received with a 390 Flow Label value that does not match INCOMING_FLOW_ID MUST be 391 silently discarded. If a significant number of such packets are 392 received, this event SHOULD be logged. 394 When a server implements a SYN cache and/or SYN cookies, the Flow 395 Label value used in the SYN-ACK packet MUST be consistent with the 396 Flow Label value used in subsequent packets [McGann05] [RFC4987]. 397 For the SYN cache case, this can be handled easily by including 398 INCOMING_FLOW_ID and OUTGOING_FLOW_ID as part of each cache entry. 399 For SYN cookies, one approach to satisfying the requirement without 400 storing state is to derive the Flow Label value from a hash of the 401 the connection 4-tuple plus a random secret [McGann05]. Another 402 approach is to use the Flow Label value received in the SYN 403 (INCOMING_FLOW_ID) as the Flow Label value in the SYN-ACK 404 (OUTGOING_FLOW_ID). When the connection is established, the same 405 Flow Label value will be used in both directions of traffic. This 406 approach leaves a small window of vulnerability to spoofing before 407 the connection is established. 409 [RFC0793] specifies that a connection should remain in TIME_WAIT 410 state for 2 * MSL (Maximum Segment Lifetime) seconds. [RFC0793] 411 specifies MSL as 120 seconds, although many implementations default 412 to a lower value. The Flow Label value quarantine period MUST be no 413 less than the maximum of either 2 * MSL for the connection, or 120 414 seconds. 416 The specified behavior at the client and server will work even if 417 either the client or server fails to set a non-zero outgoing Flow 418 Label value, or check the incoming Flow Label value. However, 419 resistance to spoofing attacks is not improved. Further, no 420 mechanism for detecting whether a peer is supporting the Flow Label 421 nonce is defined, although receipt of an initial packet with a non- 422 zero Flow Label suggests that the sending host may support this 423 specification. Therefore, some cryptographic authentication 424 mechanism SHOULD be used when operating in a high-threat environment 425 [RFC2385][I-D.ietf-tcpm-tcp-auth-opt] [RFC4301]. 427 5. UDP Considerations 429 UDP is a connectionless protocol, which is also vulnerable to 430 spoofing attacks. The level of vulnerability is specific to each 431 application-layer protocol running over UDP. Source port 432 randomization can be utilized with UDP, but UDP does not have 433 sequence numbers, so it is arguably more vulnerable than TCP with 434 source port and initial sequence number randomization. With the 435 exception of connected SOCk_DGRAM sockets, UDP/IP stacks (usually) do 436 not maintain sufficient state to maintain INCOMING_FLOW_ID or 437 OUTGOING_FLOW_ID values for each application data stream between a 438 source host and a destination host or multicast group. Therefore, 439 Flow Label generation and validation must happen at the application 440 layer. 442 For purposes of discussion, we define a UDP connection as a flow of 443 traffic matching the tuple . Note that a UDP 445 connection consists of uni-directional traffic flow between a pair of 446 hosts, or between a host and the receivers of a multicast group. UDP 447 applications MUST assign each connection to a unique flow, and hence 448 MUST assign each connection a unique Flow Label value. One exception 449 is where multiple application data streams are multiplexed onto the 450 same address/port pairs. In this case UDP applications MUST assign 451 application data streams to unique flows (as appropriate for the 452 intended QoS or other handling), and MUST use application-layer 453 demultiplexing to associate incoming data streams with flows. 454 Maintenance of INCOMING_FLOW_ID and OUTGOING_FLOW_ID values for each 455 flow MUST be provided by the application. Applications MUST check 456 the Flow Label value of a received packet against INCOMING_FLOW_ID 457 for the associated flow, and MUST silently discard the packet if the 458 values do not match. If a significant number of such packets are 459 received, this event SHOULD be logged. Note that an alternative to 460 multiplexing multiple application data streams onto the same address/ 461 port pair is to utilize different source and/or destination port 462 values for each data stream. 464 Note that the Flow Label nonce does not provide any additional 465 protection for multicast applications. Source address spoofing is 466 usually prevented through use of reverse path forwarding (RPF) checks 467 as part of the multicast forwarding procedure, and in cases where RPF 468 is not in use (e.g., in BIDIR-PIM) [RFC5015][RFC5294], the attacker 469 can learn the Flow Label values used by one or more senders by 470 joining the multicast group. 472 There is no standard, widely implemented sockets API for either 473 setting the Flow Label value in outgoing packets, nor retrieving it 474 in incoming packets [RFC3493][RFC3542]. There is also no standard 475 sockets API for specifying that a non-zero Flow Label value be used 476 in outgoing packets. Therefore the requirements above cannot be 477 satisfied, except where a non-standard API is available, or the 478 functionality is provided automatically within the UDP/IP stack. It 479 would be worthwhile to define a standard sockets API for Flow Label 480 management. 482 One application where the use of the Flow Label as a nonce would be 483 beneficial is in protection against blind DNS cache poisoning attacks 484 [I-D.weaver-dnsext-comprehensive-resolver]. If DNS queries are each 485 assigned a unique Flow Label value, and if DNS servers send responses 486 with an outgoing Flow Label value equal to the incoming Flow Label 487 value received in the request, then the client can validate with 488 high-probability that the request was generated by the targeted 489 server, since the UDP source port, DNS transaction ID, and Flow Label 490 together provide approximately 51 bits of entropy. 492 The procedures described above for UDP are equally applicable for 493 UDP-Lite [RFC3828]. 495 6. SCTP Considerations 497 Use of the Flow Label with SCTP will be discussed in a subsequent 498 revision of this document. 500 7. DCCP Considerations 502 Use of the Flow Label with DCCP will be discussed in a subsequent 503 revision of this document. 505 8. RTP Considerations 507 Use of the Flow Label with RTP applications will be discussed in a 508 subsequent revision of this document. 510 9. NAT Considerations 512 IPv6 network address translators (NATs) are not common, and there is 513 no widely accepted definition for their correct behavior. One 514 proposal [I-D.mrw-behave-nat66] assumes that the NAT66 device 515 performs stateless one-to-one address translation between internal 516 and external addresses. In this scenario there is no address 517 multiplexing, and the Flow Label values SHOULD NOT be changed by the 518 NAT66 device. The same is true for protocols permitting locator 519 translation, such as ILNP [I-D.rja-ilnp-intro]. 521 An IPv6 NAT device performing address multiplexing (e.g., a NAPT) 522 must obey the same Flow Label rules in Section 3 as any host; i.e., 523 no two independent flows originating from the same translated address 524 may share the same Flow Label value. Therefore, such a NAT device 525 MUST modify the Flow Label value of any arriving flow of packets to 526 ensure that it does not collide with any currently in-use Flow Label 527 values originating from the same translated address. 529 10. Support for Transport Connection Sub-Flows 531 The procedures described in this specification mandate that each 532 transport connection must be assigned to a new flow with a unique 533 Flow Label value. This does not permit the use of multiple IPv6 534 flows within a TCP connection. Such a capability would be useful for 535 some approaches to TCP multi-path, such as 536 [I-D.van-beijnum-1e-mp-tcp], which use the same address/port pairs 537 for all sub-flows of the connection, and which would like to utilize 538 the IPv6 Flow Label as part of the ECMP load balancing key in 539 routers. 541 To enable the instantiation of multiple IPv6 flows per-transport 542 connection, while retaining the benefits of the Flow Label as a 543 nonce, we propose the following alternative procedures: 545 o Source hosts MUST assign each flow within a single transport 546 connection with an OUTGOING_FLOW_ID sharing the same value for the 547 least-significant 16 bits. 549 o Destination hosts check on the least-significant 16 bits of 550 INCOMING_FLOW_ID for each transport connection. 552 This modified procedure does not significantly weaken the overall 553 strenght of Flow Label nonce mechanism (when combined with other 554 obfuscation techniques), while enabling up to 16 sub-flows per- 555 transport connection). 557 11. Acknowledgements 559 [McGann05] describes the use of the Flow Label as a transport-layer 560 nonce. If others are aware of when and where this concept might have 561 been discussed previously, please contact the author. 563 The author would like to thank Brian Carpenter, Gorry Fairhurst, Joe 564 Touch, Bob Briscoe, Iljitsch van Beijnum, and Marcelo Bagnulo Braun 565 for their valuable feedback. 567 This document was produced using the xml2rfc tool [RFC2629]. 569 12. IANA Considerations 571 This memo includes no request to IANA. 573 13. Security Considerations 575 This memo describes the use of the IPv6 Flow Label as a transport- 576 layer nonce to help protect transport connections and application 577 data streams from blind spoofed packet injection attacks. Blind 578 spoofed packet injection attacks have been described in several 579 publications, and are well known to the community. This memo 580 addresses the use of this mechanism with different transport 581 protocols. This mechanism is only applicable for hosts communicating 582 via the IPv6 protocol. This mechanism does not provide protection 583 for any on-path (man-in-the-middle attacks); therefore, additional 584 security mechanisms should be used in high threat environments. 586 14. References 588 14.1. Normative References 590 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 591 August 1980. 593 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 594 RFC 793, September 1981. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 600 (IPv6) Specification", RFC 2460, December 1998. 602 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 603 Jacobson, "RTP: A Transport Protocol for Real-Time 604 Applications", STD 64, RFC 3550, July 2003. 606 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 607 "IPv6 Flow Label Specification", RFC 3697, March 2004. 609 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 610 G. Fairhurst, "The Lightweight User Datagram Protocol 611 (UDP-Lite)", RFC 3828, July 2004. 613 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 614 Requirements for Security", BCP 106, RFC 4086, June 2005. 616 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 617 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 619 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 620 Message Protocol (ICMPv6) for the Internet Protocol 621 Version 6 (IPv6) Specification", RFC 4443, March 2006. 623 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 624 RFC 4960, September 2007. 626 14.2. Informative References 628 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 629 RFC 1948, May 1996. 631 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 632 Signature Option", RFC 2385, August 1998. 634 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 635 June 1999. 637 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 638 Defeating Denial of Service Attacks which employ IP Source 639 Address Spoofing", BCP 38, RFC 2827, May 2000. 641 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 642 Stevens, "Basic Socket Interface Extensions for IPv6", 643 RFC 3493, February 2003. 645 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 646 "Advanced Sockets Application Program Interface (API) for 647 IPv6", RFC 3542, May 2003. 649 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 650 Networks", BCP 84, RFC 3704, March 2004. 652 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 653 Internet Protocol", RFC 4301, December 2005. 655 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 656 RFC 4953, July 2007. 658 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 659 Mitigations", RFC 4987, August 2007. 661 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 662 "Bidirectional Protocol Independent Multicast (BIDIR- 663 PIM)", RFC 5015, October 2007. 665 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 666 Pignataro, "The Generalized TTL Security Mechanism 667 (GTSM)", RFC 5082, October 2007. 669 [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol 670 Independent Multicast (PIM)", RFC 5294, August 2008. 672 [I-D.ietf-tcpm-icmp-attacks] 673 Gont, F., "ICMP attacks against TCP", 674 draft-ietf-tcpm-icmp-attacks-03 (work in progress), 675 March 2008. 677 [I-D.ietf-tcpm-tcpsecure] 678 Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 679 Robustness to Blind In-Window Attacks", 680 draft-ietf-tcpm-tcpsecure-10 (work in progress), 681 July 2008. 683 [I-D.ietf-tsvwg-port-randomization] 684 Larsen, M. and F. Gont, "Port Randomization", 685 draft-ietf-tsvwg-port-randomization-02 (work in progress), 686 August 2008. 688 [I-D.ietf-tcpm-tcp-auth-opt] 689 Touch, J., Mankin, A., and R. Bonica, "The TCP 690 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-01 691 (work in progress), July 2008. 693 [I-D.weaver-dnsext-comprehensive-resolver] 694 Weaver, N., "Comprehensive DNS Resolver Defenses Against 695 Cache Poisoning", 696 draft-weaver-dnsext-comprehensive-resolver-00 (work in 697 progress), September 2008. 699 [I-D.mrw-behave-nat66] 700 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 701 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 702 progress), March 2009. 704 [I-D.rja-ilnp-intro] 705 Atkinson, R., "ILNP Concept of Operations", 706 draft-rja-ilnp-intro-02 (work in progress), December 2008. 708 [I-D.van-beijnum-1e-mp-tcp] 709 Beijnum, I., "One-ended multipath TCP", 710 draft-van-beijnum-1e-mp-tcp-00 (work in progress), 711 May 2009. 713 [McGann05] 714 McGann, O. and D. Malone, "Flow Label Filtering 715 Feasibility", European Conference on Computer Network 716 Defence, December 2005. 718 Author's Address 720 Steven Blake 721 Extreme Networks 722 Pamlico Building One, Suite 100 723 3306/08 E. NC Hwy 54 724 RTP, NC 27709 725 USA 727 Phone: +1 919 884 3211 728 Email: sblake@extremenetworks.com