idnits 2.17.1 draft-blake-ipv6-flow-label-nonce-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 641. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5647 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 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 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 November 3, 2008 5 Expires: May 7, 2009 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-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 TCP and other transport-layer protocols are vulnerable to spoofing 39 attacks from off-path hosts. These attacks can be prevented through 40 the use of cryptographic authentication. However, it is difficult to 41 use cryptographic authentication in all circumstances. A variety of 42 obfuscation techniques -- such as initial sequence number 43 randomization and source port randomization -- increase the effort 44 required of an attacker to successfully guess the packet header 45 fields which uniquely identify a transport connection. This memo 46 proposes the use of the IPv6 Flow Label field as a random, per- 47 connection nonce value, to add entropy to the set of packet header 48 fields used to identify a transport connection. This mechanism is 49 easily implementable, allows for incremental deployment, and is fully 50 compliant with the rules for Flow Label use defined in RFC 3697. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 56 3. Additional Requirements on Flow Label Value Generation and 57 Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. TCP Considerations . . . . . . . . . . . . . . . . . . . . . . 7 59 5. UDP Considerations . . . . . . . . . . . . . . . . . . . . . . 9 60 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 7. DCCP Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . . 10 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 12.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 Recent effort has been directed towards identifying and reducing the 75 vulnerability of TCP [RFC0793] to a variety of "blind" spoofed packet 76 injection attacks from hosts that are off-path (i.e., not able to 77 intercept communications between a pair of hosts) [RFC4953][RFC5082] 78 [I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-tcpsecure] 79 [I-D.ietf-tsvwg-port-randomization]. Off-path spoofing attacks 80 against TCP require an attacker to correctly guess the 4-tuple of 81 header fields uniquely identifying a TCP connection, 83 along with a valid (in-receive window) value for the 32-bit TCP 84 sequence number. By correctly guessing values for these fields, an 85 attacker is then able to inject ACK, DATA, RST, of SYN segments into 86 a TCP connection, enabling throughput reduction, data corruption, or 87 connection termination. Similarly, by correctly guessing values for 88 these fields, an attacker is able to forge ICMP messages to a host, 89 with similar negative consequences [I-D.ietf-tcpm-icmp-attacks]. 91 Increased use of long-duration connections by applications, as well 92 as faster access link speeds, increase the ability of attackers to 93 transmit a sufficient number of spoof packets to successfully attack 94 a connection, especially when either the destination or source ports 95 are easily guessable. Cryptographic authentication mechanisms such 96 as the TCP MD5 Authentication Option [RFC2385], TCP Authentication 97 Option [I-D.ietf-tcpm-tcp-auth-opt], and IPsec [RFC4301] can secure 98 against these attacks, as well as some on-path (man-in-the-middle) 99 attacks. However, key management and computational overhead makes 100 the deployment of cryptographic authentication prohibitively 101 expensive in some environments and for applications. 103 Network ingress filtering of IP source addresses has been widely 104 deployed at network boundaries, significantly reducing the set of 105 networks that a particular host can inject spoof packets into 106 [RFC2827][RFC3704]. But network ingress filtering is not universally 107 deployed, leaving many networks vulnerable to spoofed packet attacks. 108 Note also that network ingress filtering typically provides no 109 protection against ICMP spoofing attacks, since the attacker does not 110 need to spoof the IP source address in the ICMP packet header (only 111 the IP destination address in the ICMP message payload). 113 Obfuscation techniques can be employed to increase the effort 114 required of an attacker. Initial sequence number randomization 115 [RFC1948] [I-D.ietf-tcpm-tcpsecure] can be implemented by both the 116 client (the host initiating a connection) and server. For typical 117 window sizes of approximately 32 Kbytes, this technique forces an 118 attacker to send approximately 57000 RST packets on average to reset 119 a connection [RFC4953]. Source port randomization 121 [I-D.ietf-tsvwg-port-randomization] can also be implemented by a 122 client to increase the number of guesses an attacker must make to 123 successfully attack a connection. This mechanism can provide an 124 additional ~15 bits of entropy (depending on implementation). Source 125 port randomization can also be used with other transport protocols. 127 Both obfuscation schemes are compliant with [RFC0793], and are 128 incrementally deployable. Both schemes used in combination introduce 129 somewhat less than 32 bits of entropy (~16 + ~15). However, as 130 access link speeds (and consequently, receive windows) increase in 131 size, the amount of entropy declines just as the number of spoof 132 packets an attacker can generate in a given interval increases. 133 [I-D.weaver-dnsext-comprehensive-resolver] argues that 40 bits of 134 entropy is desirable to make off-path spoofing attacks impractical. 136 IPv6 [RFC2460] includes a 20-bit Flow Label field, which can be used 137 by hosts to uniquely label a uni-directional sequence of packets from 138 a host to a particular unicast, anycast, or multicast destination. 139 The tuple of 140 uniquely identifies a particular flow during its lifetime (plus a 141 subsequent quarantine period). Rules for the generation and usage of 142 Flow Label values are defined in [RFC3697]. Because transport-layer 143 port fields may be located at a variable offset within a packet due 144 to IPv6 extension headers, or may be obscured due to encryption, the 145 Flow Label provides a fixed field in the IPv6 header to facilitate 146 flow classification in routers. 148 While originally intended to facilitate flow-specific packet handling 149 in routers (e.g., QoS, fast switching), the Flow Label can also be 150 used by hosts to uniquely label one or more transport connections. 151 An originating host can select a random Flow Label value at the 152 beginning of a connection, and continue to use it for the 153 connection's duration. The host (or hosts for multicast) at the 154 other end of the connection can record this Flow Label value, and use 155 it as part of the connection demultiplexing key, while also labeling 156 response packets with the same or a different Flow Label value. The 157 originating host can similarly record the Flow Label value in 158 response packets, and use it as part of its connection demultiplexing 159 key. In this way an additional 20 bits of entropy is added to the 160 set of header fields used to identify a transport connection. When 161 used in addition to source port randomization, the total amount of 162 entropy is approximately 34-35 bits. When initial sequence number 163 randomization is also used (i.e., in TCP), the entropy is increased 164 to > 40 bits, making off-path snooping attacks impractical. 166 The concept of labeling transport connections to prevent off-path 167 spoofing attacks was proposed in [McGann05], in the context of 168 stateful firewalls. This scheme may be useful for other transport 169 protocols such as SCTP [RFC4960], UDP [RFC0768], UDP-Lite [RFC3828], 170 DCCP [RFC4340], and RTP [RFC3550]. Host implementations in 171 compliance with [RFC3697] which do not allocate multiple flows to a 172 single transport connection will either label all packets in the 173 connection with a Flow Label value of 0, or with some other constant. 174 Therefore, this scheme is incrementally deployable by either peer in 175 a connection. 177 Section 3 specifies additional requirements on Flow Label generation. 178 Section 4 describes the use of this scheme with TCP. Section 5 179 describes the use of this scheme with UDP and UDP-Lite. Section 6 180 describes the use of this scheme with SCTP. Section 7 describes the 181 use of this scheme with DCCP. Section 8 describes the use of this 182 scheme with RTP over UDP or DCCP. 184 2. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 3. Additional Requirements on Flow Label Value Generation and Use 192 [RFC3697] specifies the rules governing use of the IPv6 Flow Label. 193 The primary requirements relevant to our purpose are as follows 194 (quoting directly): 196 o The Flow Label value set by the source MUST be delivered unchanged 197 to the destination node(s). 199 o To enable Flow Label based classification, source nodes SHOULD 200 assign each unrelated transport connection and application data 201 stream to a new flow. 203 o The source node SHOULD be able to select unused Flow Label values 204 for flows not requesting a specific value to be used. 206 o A source node MUST ensure that it does not unintentionally reuse 207 Flow Label values it is currently using or has recently used when 208 creating new flows. 210 o Flow Label values previously used with a specific pair of source 211 and destination addresses MUST NOT be assigned to new flows with 212 the same address pair within 120 seconds of the termination of the 213 previous flow. 215 o The source node SHOULD provide the means for the applications and 216 transport protocols to specify quarantine periods longer than the 217 default 120 seconds for individual flows. 219 o To avoid accidental Flow Label value reuse, the source node SHOULD 220 select the new Flow Label value in a well-defined sequence, (e.g., 221 sequential or pseudo-random) and use an initial value that avoids 222 reuse of recently used Flow Label values each time the system 223 restarts. The initial value SHOULD be derived from a previous 224 value stored in non-volatile memory, or in the absence of such 225 history, a randomly generated initial value using techniques that 226 produce good randomness properties SHOULD be used. 228 We wish to use the Flow Label value as an unguessable nonce. Hence, 229 the following additional requirements are implied: 231 o Source hosts MUST assign each unrelated transport connection and 232 application data stream to a new flow. 234 o Source hosts MUST be able to select unused Flow Label values for 235 flows not requesting a specific value to be used. The selected 236 Flow Label value must remain constant for the duration of the 237 flow. 239 o The Flow Label value MUST be practically unguessable, in a manner 240 similar to the TCP source port or initial sequence number when 241 they are randomized. A random number generator with good 242 randomness properties (i.e., uniformly distributed) as specified 243 in [RFC4086] MUST be used to generate Flow Label values not 244 explicitly requested by an application. 246 o Flow Label state for a transport connection or application data 247 stream MUST be cleaned-up by the destination host(s) as part of 248 the transport connection/application data stream state clean-up. 250 o Flow Label values previously used with a specific pair of source 251 and destination addresses MUST NOT be assigned to new flows with 252 the same address pair within X seconds of the termination of the 253 previous flow, where X is the maximum of either 120 seconds, or 254 the duration for which transport connection state might linger at 255 a destination host after traffic flow has ceased (e.g., TIME-WAIT 256 state in TCP). 258 For this application of the Flow Label field, it would not pose a 259 problem if multiple flows from a source host in unrelated transport 260 connections/application data streams coincidentally shared the same 261 Flow Label value, as long as the other previous requirements are 262 adhered to. However, the prohibition in [RFC3697] against 263 simultaneous reuse of Flow Label values MUST be observed. Any 264 application request to assign a specific Flow Label value already in 265 use by another flow MUST be rejected. 267 Transport-specific requirements on Flow Label use are provided in the 268 subsequent sections. However, as a general requirement, if a packet 269 is received on a transport connection/application data stream with an 270 unexpected Flow Label value, the packet MUST be silently discarded. 271 If excessive Flow Label errors are received, this event SHOULD be 272 logged. 274 ICMPv6 error messages contain the IPv6 header of the packet 275 triggering the error [RFC4443]. A host receiving an ICMPv6 error 276 message can validate the Flow Label value in the message payload to 277 protect against ICMPv6 spoofing attacks [I-D.ietf-tcpm-icmp-attacks]. 279 Use of the Flow Label value as an unguessable nonce is incrementally 280 deployable, whether a source host fails to support setting the Flow 281 Label to a non-zero value, or a destination host fails to check its 282 value. However, a Flow Label value of 0 is easily guessable, so 283 resistance to spoofing attacks is not improved. Hosts SHOULD NOT 284 rely on the mechanisms defined in this document when operating in 285 high-threat environments. 287 The additional requirements given here for Flow Label generation and 288 use are not in conflict with the requirements in [RFC3697]. 289 Therefore, additional applications of the Flow Label field (e.g., for 290 special QoS handling, load balancing, etc.) can be applied 291 simultaneously with the use of the Flow Label field as a transport- 292 layer nonce, so long as an additional application does not limit the 293 permissible values of the Flow Label in any way which violates the 294 requirement that the value be unpredictable. 296 4. TCP Considerations 298 Uni-directional traffic in a TCP connection is assumed to constitute 299 a single flow, and hence MUST be assigned a unique Flow Label value 300 by the source host; either explicitly by the application or 301 automatically by the host's TCP/IP stack. Given the Flow Label 302 value's additional use as a packet classification field in routers 303 (for QoS or other purposes), there is no compelling reason to sub- 304 divide traffic within a TCP connection into multiple flows for 305 classification purposes. 307 For this application of the Flow Label field, it would not pose a 308 problem if multiple TCP connections from a source host (whether to 309 one or a multiple of destination hosts) reused the same Flow Label 310 value. However, because of the additional uses of the Flow Label 311 field, a host MUST NOT assign the same Flow Label value to multiple 312 TCP connections. Both directions of traffic flow in a TCP connection 313 are not required to share the same Flow Label value, nor are they 314 prohibited from doing so. 316 A host originating a TCP connection (client) selects a unique Flow 317 Label value for the connection, which it stores as the 318 OUTGOING_FLOW_ID in its Transport Control Block (TCB) for this 319 connection. The Flow Label selection algorithm can run 320 simultaneously with TCP source port and initial sequence number 321 selection (e.g., by generating a single random variable and assigning 322 bit-ranges within it to each field). This Flow Label value is 323 included in the first (and subsequent) SYN packet(s) sent to the 324 destination host (server). The server receiving the first SYN packet 325 records the Flow Label value in its TCB for this connection as the 326 INCOMING_FLOW_ID. The server then selects a unique Flow Label value 327 for the connection, which it stores as the OUTGOING_FLOW_ID in the 328 connection's TCB. It includes this Flow Label value in the first 329 (and subsequent) SYN-ACK packet(s) sent to the client. The client 330 receiving the SYN-ACK packet from the server records the Flow Label 331 value in its TCB for this connection as the INCOMING_FLOW_ID. It 332 sends all additional packets of the connection to the server using 333 OUTGOING_FLOW_ID, and checks all incoming packets of the connection 334 from the server to ensure that they include INCOMING_FLOW_ID. The 335 server performs identical processing. Any packets received with a 336 Flow Label value that does not match INCOMING_FLOW_ID MUST be 337 silently discarded. If a significant number of such packets are 338 received, this event SHOULD be logged. 340 When a server implements a SYN cache and/or SYN cookies, the Flow 341 Label value used in the SYN-ACK packet MUST be consistent with the 342 Flow Label value used in subsequent packets [McGann05] [RFC4987]. 343 For the SYN cache case, this can be handled easily by including 344 INCOMING_FLOW_ID and OUTGOING_FLOW_ID as part of each cache entry. 345 For SYN cookies, one approach to satisfying the requirement without 346 storing state is to derive the Flow Label value from a hash of the 347 the connection 4-tuple plus a random secret [McGann05]. Another 348 approach is to use the Flow Label value received in the SYN 349 (INCOMING_FLOW_ID) as the Flow Label value in the SYN-ACK 350 (OUTGOING_FLOW_ID). When the connection is established, the same 351 Flow Label value will be used in both directions of traffic. This 352 approach leaves a small window of vulnerability to spoofing before 353 the connection is established. 355 [RFC0793] specifies that a connection should remain in TIME_WAIT 356 state for 2 * MSL (Maximum Segment Lifetime) seconds. [RFC0793] 357 specifies MSL as 120 seconds, although many implementations default 358 to a lower value. The Flow Label value quarantine period MUST be no 359 less than the maximum of either 2 * MSL for the connection, or 120 360 seconds. 362 The specified behavior at the client and server will work even if 363 either the client or server fails to set a non-zero outgoing Flow 364 Label value, or check the incoming Flow Label value. However, 365 resistance to spoofing attacks is not improved. Further, no 366 mechanism for detecting whether a peer is supporting the Flow Label 367 nonce is defined. Therefore, some cryptographic authentication 368 mechanism SHOULD BE used when operating in a high-threat environment 369 [RFC2385][I-D.ietf-tcpm-tcp-auth-opt] [RFC4301]. 371 5. UDP Considerations 373 UDP is a connectionless protocol, which is also vulnerable to 374 spoofing attacks. The level of vulnerability is specific to each 375 application-layer protocol running over UDP. Source port 376 randomization can be utilized with UDP, but UDP does not have 377 sequence numbers, so it is arguably more vulnerable than TCP with 378 source port and initial sequence number randomization. With the 379 exception of connected SOCk_DGRAM sockets, UDP/IP stacks (usually) do 380 not maintain sufficient state to maintain INCOMING_FLOW_ID or 381 OUTGOING_FLOW_ID values for each application data stream between a 382 source host and a destination host or multicast group. Therefore, 383 Flow Label generation and validation must happen at the application 384 layer. 386 For purposes of discussion, we define a UDP connection as a flow of 387 traffic matching the tuple . Note that a UDP 389 connection consists of uni-directional traffic flow between a pair of 390 hosts, or between a host and the receivers of a multicast group. UDP 391 applications MUST assign each connection to a unique flow, and hence 392 MUST assign each connection a unique Flow Label value. One exception 393 is where multiple application data streams are multiplexed onto the 394 same address/port pairs. In this case UDP applications MUST assign 395 application data streams to unique flows (as appropriate for the 396 intended QoS or other handling), and MUST use application-layer 397 demultiplexing to associate incoming data streams with flows. 398 Maintenance of INCOMING_FLOW_ID and OUTGOING_FLOW_ID values for each 399 flow MUST be provided by the application. Applications MUST check 400 the Flow Label value of a received packet against INCOMING_FLOW_ID 401 for the associated flow, and MUST silently discard the packet if the 402 values do not match. If a significant number of such packets are 403 received, this event SHOULD be logged. Note that an alternative to 404 multiplexing multiple application data streams onto the same address/ 405 port pair is to utilize different source and/or destination port 406 values for each data stream. 408 There is no standard sockets API for either setting the Flow Label 409 value in outgoing packets, nor retrieving it in incoming packets 410 [RFC3493][RFC3542]. There is also no standard sockets API for 411 specifying that a non-zero Flow Label value be used in outgoing 412 packets. Therefore the requirements above cannot be satisfied, 413 except where a non-standard API is available, or the functionality is 414 provided automatically within the UDP/IP stack. It would be 415 worthwhile to define a standard sockets API for Flow Label 416 management. 418 One application where the use of the Flow Label as a nonce would be 419 beneficial is in protection against blind DNS cache poisoning attacks 420 [I-D.weaver-dnsext-comprehensive-resolver]. If DNS queries are each 421 assigned a unique Flow Label value, and if DNS servers send responses 422 with an outgoing Flow Label value equal to the incoming Flow Label 423 value received in the request, then the client can validate with 424 high-probability that the request was generated by the targeted 425 server, since the UDP source port, DNS transaction ID, and Flow Label 426 together provide approximately 51 bits of entropy. 428 UDP-Lite [RFC3828] differs from UDP by allowing an application to 429 exclude parts of the payload from the UDP-Lite checksum. Since the 430 Flow Label field is not part of the UDP-Lite pseudo header [RFC2460], 431 its value could be altered by data transmission errors (that are not 432 corrected or rejected by the data link layer) that are not detected 433 by the destination. Therefore, UDP-Lite applications SHOULD NOT 434 check the Flow Label value received in packets of a data stream 435 carried over UDP-Lite. 437 6. SCTP Considerations 439 Use of the Flow Label with SCTP will be discussed in a subsequent 440 revision of this document. 442 7. DCCP Considerations 444 Use of the Flow Label with DCCP will be discussed in a subsequent 445 revision of this document. 447 8. RTP Considerations 449 Use of the Flow Label with RTP applications will be discussed in a 450 subsequent revision of this document. 452 9. Acknowledgements 454 [McGann05] describes the use of the Flow Label as a transport-layer 455 nonce. If others are aware of when and where this concept might have 456 been discussed previously, please contact the author. 458 The author would like to thank Brian Carpenter for his valuable 459 feedback. 461 This document was produced using the xml2rfc tool [RFC2629]. 463 10. IANA Considerations 465 This memo includes no request to IANA. 467 11. Security Considerations 469 This memo describes the use of the IPv6 Flow Label as a transport- 470 layer nonce to help protect transport connections and application 471 data streams from blind spoofed packet injection attacks. Blind 472 spoofed packet injection attacks have been described in several 473 publications, and are well known to the community. This memo 474 addresses the use of this mechanism with different transport 475 protocols. This mechanism is only applicable for hosts communicating 476 via the IPv6 protocol. This mechanism does not provide protection 477 for any on-path (man-in-the-middle attacks); therefore, additional 478 security mechanisms must be used in high threat environments. 480 12. References 482 12.1. Normative References 484 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 485 August 1980. 487 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 488 RFC 793, September 1981. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 494 (IPv6) Specification", RFC 2460, December 1998. 496 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 497 Jacobson, "RTP: A Transport Protocol for Real-Time 498 Applications", STD 64, RFC 3550, July 2003. 500 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 501 "IPv6 Flow Label Specification", RFC 3697, March 2004. 503 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 504 G. Fairhurst, "The Lightweight User Datagram Protocol 505 (UDP-Lite)", RFC 3828, July 2004. 507 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 508 Requirements for Security", BCP 106, RFC 4086, June 2005. 510 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 511 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 513 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 514 Message Protocol (ICMPv6) for the Internet Protocol 515 Version 6 (IPv6) Specification", RFC 4443, March 2006. 517 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 518 RFC 4960, September 2007. 520 12.2. Informative References 522 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 523 RFC 1948, May 1996. 525 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 526 Signature Option", RFC 2385, August 1998. 528 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 529 June 1999. 531 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 532 Defeating Denial of Service Attacks which employ IP Source 533 Address Spoofing", BCP 38, RFC 2827, May 2000. 535 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 536 Stevens, "Basic Socket Interface Extensions for IPv6", 537 RFC 3493, February 2003. 539 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 540 "Advanced Sockets Application Program Interface (API) for 541 IPv6", RFC 3542, May 2003. 543 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 544 Networks", BCP 84, RFC 3704, March 2004. 546 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 547 Internet Protocol", RFC 4301, December 2005. 549 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 550 RFC 4953, July 2007. 552 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 553 Mitigations", RFC 4987, August 2007. 555 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 556 Pignataro, "The Generalized TTL Security Mechanism 557 (GTSM)", RFC 5082, October 2007. 559 [I-D.ietf-tcpm-icmp-attacks] 560 Gont, F., "ICMP attacks against TCP", 561 draft-ietf-tcpm-icmp-attacks-03 (work in progress), 562 March 2008. 564 [I-D.ietf-tcpm-tcpsecure] 565 Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 566 Robustness to Blind In-Window Attacks", 567 draft-ietf-tcpm-tcpsecure-10 (work in progress), 568 July 2008. 570 [I-D.ietf-tsvwg-port-randomization] 571 Larsen, M. and F. Gont, "Port Randomization", 572 draft-ietf-tsvwg-port-randomization-02 (work in progress), 573 August 2008. 575 [I-D.ietf-tcpm-tcp-auth-opt] 576 Touch, J., Mankin, A., and R. Bonica, "The TCP 577 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-01 578 (work in progress), July 2008. 580 [I-D.weaver-dnsext-comprehensive-resolver] 581 Weaver, N., "Comprehensive DNS Resolver Defenses Against 582 Cache Poisoning", 583 draft-weaver-dnsext-comprehensive-resolver-00 (work in 584 progress), September 2008. 586 [McGann05] 587 McGann, O. and D. Malone, "Flow Label Filtering 588 Feasibility", European Conference on Computer Network 589 Defence, December 2005. 591 Author's Address 593 Steven Blake 594 Extreme Networks 595 Pamlico Building One, Suite 100 596 3306/08 E. NC Hwy 54 597 RTP, NC 27709 598 USA 600 Phone: +1 919 884 3211 601 Email: sblake@extremenetworks.com 603 Full Copyright Statement 605 Copyright (C) The IETF Trust (2008). 607 This document is subject to the rights, licenses and restrictions 608 contained in BCP 78, and except as set forth therein, the authors 609 retain all their rights. 611 This document and the information contained herein are provided on an 612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 614 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 615 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 616 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Intellectual Property 621 The IETF takes no position regarding the validity or scope of any 622 Intellectual Property Rights or other rights that might be claimed to 623 pertain to the implementation or use of the technology described in 624 this document or the extent to which any license under such rights 625 might or might not be available; nor does it represent that it has 626 made any independent effort to identify any such rights. Information 627 on the procedures with respect to rights in RFC documents can be 628 found in BCP 78 and BCP 79. 630 Copies of IPR disclosures made to the IETF Secretariat and any 631 assurances of licenses to be made available, or the result of an 632 attempt made to obtain a general license or permission for the use of 633 such proprietary rights by implementers or users of this 634 specification can be obtained from the IETF on-line IPR repository at 635 http://www.ietf.org/ipr. 637 The IETF invites any interested party to bring to its attention any 638 copyrights, patents or patent applications, or other proprietary 639 rights that may cover technology that may be required to implement 640 this standard. Please address the information to the IETF at 641 ietf-ipr@ietf.org.