idnits 2.17.1 draft-blake-ipv6-flow-label-nonce-00.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 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 589. 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 (October 27, 2008) is 5659 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 1948 (Obsoleted by RFC 6528) ** 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 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: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 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 27, 2008 5 Expires: April 30, 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-00 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 April 30, 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 spoof 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 . . . . . . . . . . . . . . . . . . . . . . 8 60 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 7. DCCP Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . . 10 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 12.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 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 sender, 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 applications. 103 Obfuscation techniques can be employed to increase the effort 104 required of an attacker. Initial sequence number randomization 105 [RFC1948] [I-D.ietf-tcpm-tcpsecure] can be implemented by both the 106 client (the host initiating a connection) and server. For typical 107 window sizes of approximately 32 Kbytes, this technique forces an 108 attacker to send approximately 57000 RST packets on average to reset 109 a connection [RFC4953]. Source port randomization 110 [I-D.ietf-tsvwg-port-randomization] can also be implemented by a 111 client to increase the number of guesses an attacker must make to 112 successfully attack a connection. This mechanism can provide an 113 additional ~15 bits of entropy (depending on implementation). Source 114 port randomization can also be used with other transport protocols. 116 Both obfuscation schemes are compliant with [RFC0793], and are 117 incrementally deployable. Both schemes used in combination introduce 118 somewhat less than 32 bits of entropy (~16 + ~15). However, as 119 access link speeds (and consequently, receive windows) increase in 120 size, the amount of entropy declines just as the number of spoof 121 packets an attacker can generate in a given interval increases. 122 [I-D.weaver-dnsext-comprehensive-resolver] argues that 40 bits of 123 entropy is desirable to make off-path spoofing attacks impractical. 125 IPv6 [RFC2460] includes a 20-bit Flow Label field, which can be used 126 by hosts to uniquely label a sequence of packets from a host to a 127 particular unicast, anycast, or multicast destination. The tuple of 128 uniquely 129 identify a particular flow during its lifetime plus a subsequent 130 quarantine period. Rules for the generation and usage of Flow Label 131 values are defined in [RFC3697]. Because transport-layer port fields 132 may be located at a variable offset within a packet due to IPv6 133 extension headers, or may be obscured due to encryption, the Flow 134 Label provides a common field in the IPv6 header to facilitate flow 135 classification in routers. 137 While originally intended to facilitate flow-specific packet handling 138 in routers (e.g., QoS, fast switching), the Flow Label can also be 139 used by hosts to uniquely label one or more transport connections. 140 An originating host can select a random Flow Label value at the 141 beginning of a connection, and continue to use it for the 142 connection's duration. The host (or hosts for multicast) at the 143 other end of the connection can record this Flow Label value, and use 144 it as part of the connection demultiplexing key, while also labeling 145 response packets with the same or different Flow Label value. The 146 originating host can similarly record the Flow Label value in 147 response packets, and use it as part of its connection demultiplexing 148 key. In this way an additional 20 bits of entropy is added to the 149 set of header fields used to identify a transport connection. When 150 used in addition to source port randomization, the total amount of 151 entropy is approximately 34-35 bits. When initial sequence number 152 randomization is also used (i.e., in TCP), the entropy is increased 153 to > 40 bits, making off-path snooping attacks impractical. 155 The concept of labeling transport connections to prevent off-path 156 spoofing attacks was proposed in [McGann05], in the context of 157 stateful firewalls. This scheme may be useful for other transport 158 protocols such as SCTP [RFC4960], UDP [RFC0768], UDP-Lite [RFC3828], 159 DCCP [RFC4340], and RTP [RFC3550]. Host implementations in 160 compliance with [RFC3697] which do not allocate multiple flows to a 161 single transport connection, will either label all packets in the 162 connection with a Flow Label value of 0, or some other constant. 163 Therefore, this scheme is incrementally deployable by either peer in 164 a connection. 166 Section 3 talks about additional requirements on Flow Label 167 generation. Section 4 talks about the use of this scheme with TCP. 169 Section 6 talks about the use of this scheme with SCTP. Section 5 170 talks about the use of this scheme with UDP and UDP-Lite. Section 7 171 talks about the use of this scheme with DCCP. Section 8 talks about 172 the use of this scheme with RTP over UDP or DCCP. 174 2. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 3. Additional Requirements on Flow Label Value Generation and Use 182 [RFC3697] specifies the rules governing use of the IPv6 Flow Label. 183 The primary requirements relevant to our purpose are as follows 184 (quoting directly): 186 o The Flow Label value set by the source MUST be delivered unchanged 187 to the destination node(s). 189 o To enable Flow Label based classification, source nodes SHOULD 190 assign each unrelated transport connection and application data 191 stream to a new flow. 193 o The source node SHOULD be able to select unused Flow Label values 194 for flows not requesting a specific value to be used. 196 o A source node MUST ensure that it does not unintentionally reuse 197 Flow Label values it is currently using or has recently used when 198 creating new flows. 200 o Flow Label values previously used with a specific pair of source 201 and destination addresses MUST NOT be assigned to new flows with 202 the same address pair within 120 seconds of the termination of the 203 previous flow. 205 o The source node SHOULD provide the means for the applications and 206 transport protocols to specify quarantine periods longer than the 207 default 120 seconds for individual flows. 209 o To avoid accidental Flow Label value reuse, the source node SHOULD 210 select the new Flow Label value in a well-defined sequence, (e.g., 211 sequential or pseudo-random) and use an initial value that avoids 212 reuse of recently used Flow Label values each time the system 213 restarts. The initial value SHOULD be derived from a previous 214 value stored in non-volatile memory, or in the absence of such 215 history, a randomly generated initial value using techniques that 216 produce good randomness properties SHOULD be used. 218 We wish to use the Flow Label value as an unguessable nonce. Hence, 219 the following additional requirements are implied: 221 o Source hosts MUST assign each unrelated transport connection and 222 application data stream to a new flow. 224 o Source hosts MUST be able to select unused Flow Label values for 225 flows not requesting a specific value to be used. The selected 226 Flow Label value must remain constant for the duration of the 227 flow. 229 o The Flow Label value MUST be practically unguessable, in a manner 230 similar to the TCP source port or initial sequence number when 231 they are randomized. A random number generator with good 232 randomness properties (i.e., uniformly distributed) as specified 233 in [RFC4086] MUST be used to generate Flow Label values not 234 explicitly requested by an application. 236 o Flow Label state for a transport connection or application data 237 stream must be cleaned-up by the destination host(s) as part of 238 the transport connection/application data stream state clean-up. 240 o Flow Label values previously used with a specific pair of source 241 and destination addresses MUST NOT be assigned to new flows with 242 the same address pair within X seconds of the termination of the 243 previous flow, where X is the maximum of either 120 seconds, or 244 the duration for which transport connection state might linger at 245 a destination host after traffic flow has ceased (e.g., TIME-WAIT 246 state in TCP). 248 For this application of the Flow Label field, it would not pose a 249 problem if multiple flows from a source host in unrelated transport 250 connections/application data streams coincidentally shared the same 251 Flow Label value, as long as the other previous requirements are 252 adhered to. However, the prohibition in [RFC3697] against 253 simultaneous reuse of Flow Label values MUST be observed. 255 Transport-specific requirements on Flow Label use are provided in the 256 subsequent sections. However, as a general requirement, if a packet 257 is received on a transport connection/application data stream with an 258 unexpected Flow Label value, the packet MUST be silently discarded. 259 If excessive Flow Label errors are received, the event SHOULD be 260 logged. 262 ICMPv6 error messages contain the IPv6 header of the packet 263 triggering the error [RFC4443]. A host receiving an ICMPv6 error 264 message can validate the Flow Label value in the message payload to 265 protect against ICMPv6 spoofing attacks [I-D.ietf-tcpm-icmp-attacks]. 267 Use of the Flow Label value as an unguessable nonce is incrementally 268 deployable, whether a source host fails to support setting the Flow 269 Label to a non-zero value, or a destination host fails to check its 270 value. However, a Flow Label value of 0 is easily guessable, so 271 resistance to spoofing attacks is not improved. Hosts SHOULD NOT 272 rely on the mechanisms defined in this document when operating in 273 high-threat environments. 275 The additional requirements given here for Flow Label generation and 276 use are not in conflict with the requirements in [RFC3697]. 277 Therefore, additional applications of the Flow Label field (e.g., 278 special QoS handling) can be applied simultaneously with the use of 279 the Flow Label field as a transport-layer nonce. 281 4. TCP Considerations 283 Unidirectional traffic in a TCP connection is assumed to constitute a 284 single flow, and hence MUST be assigned a unique Flow Label value by 285 the source host. A single TCP connection MUST NOT be treated by a 286 source host as consisting of multiple flows. Given the Flow Label 287 value's additional use as a packet classification field in routers 288 (for QoS or other purposes), there is no compelling reason to sub- 289 divide traffic within a TCP connection for classification purposes. 291 For this application of the Flow Label field, it would not pose a 292 problem if multiple TCP connections from a source host to a 293 particular destination host reused the same Flow Label value. 294 However, because of the additional uses of the Flow Label field, a 295 host MUST NOT assign the same Flow Label value to multiple TCP 296 connections. It is not assumed that both directions of traffic flow 297 in a TCP connection must share the same Flow Label value, nor it is 298 prohibited. 300 A host originating a TCP connection (client) selects a unique Flow 301 Label value for the connection, which it stores as the 302 OUTGOING_FLOW_ID in its Transport Control Block (TCB) for this 303 connection. This Flow Label value is included in the first (and 304 subsequent) SYN packet(s) sent to the destination host (server). The 305 server receiving the first SYN packet records the Flow Label value in 306 its TCB for this connection as the INCOMING_FLOW_ID. The server then 307 selects a unique Flow Label value for the connection, which it stores 308 as the OUTGOING_FLOW_ID in the connection's TCB. It includes this 309 Flow Label value in the first (and subsequent) SYN-ACK packet(s) sent 310 to the client. The client receiving the SYN-ACK packet from the 311 server records the Flow Label value in its TCB for this connection as 312 the INCOMING_FLOW_ID. It sends all additional packets of the 313 connection to the server using OUTGOING_FLOW_ID, and checks all 314 incoming packets of the connection from the server to ensure that 315 they include INCOMING_FLOW_ID. The server performs identical 316 processing. Any packets received with a Flow Label value that does 317 not match INCOMING_FLOW_ID MUST be silently discarded. If a 318 significant number of such packets are received, the event SHOULD be 319 logged. 321 When a server implements a SYN cache and/or SYN cookies, the Flow 322 Label value used in the SYN-ACK packet MUST be consistent with the 323 Flow Label value used in subsequent packets [RFC4987]. For the SYN 324 cache case, this can be handled easily by including INCOMING_FLOW_ID 325 and OUTGOING_FLOW_ID as part of each cache entry. For SYN cookies, 326 one approach to satisfying the requirement without storing state is 327 to use the Flow Label value received in the SYN (INCOMING_FLOW_ID) as 328 the Flow Label value in the SYN-ACK (OUTGOING_FLOW_ID). This 329 approach leaves a window of vulnerability to spoofing before the 330 connection is established. 332 [RFC0793] specifies that a connection should remain in TIME_WAIT 333 state for 2 * MSL (Maximum Segment Lifetime) seconds. [RFC0793] 334 specifies MSL as 120 seconds, although many implementations default 335 to a lower value. The Flow Label value quarantine period MUST be no 336 less than the maximum of either 2 * MSL for the connection, or 120 337 seconds. 339 The specified behavior at the client and server will work even if 340 either the client or server fails to set a non-zero outgoing Flow 341 Label value, or check the incoming Flow Label value. However, 342 resistance to spoofing attacks is not improved. Further, no 343 mechanism for detecting whether a peer is supporting the Flow Label 344 nonce is defined. Therefore, some cryptographic authentication 345 mechanism SHOULD BE used when operating in a high-threat environment 346 [RFC2385][I-D.ietf-tcpm-tcp-auth-opt] [RFC4301]. 348 5. UDP Considerations 350 UDP is a connectionless protocol, which is also vulnerable to 351 spoofing attacks. Source port randomization can be utilized with 352 UDP, but UDP does not have sequence numbers, so it is arguably more 353 vulnerable than TCP with source port and initial sequence number 354 randomization. With the exception of connected sockets, UDP/IP 355 stacks (usually) do not maintain sufficient state to maintain 356 INCOMING_FLOW_ID or OUTGOING_FLOW_ID values for each application data 357 stream between a source host and a destination host or multicast 358 group. Therefore, Flow Label generation and validation must happen 359 at the application layer. 361 For purposes of discussion, we define a UDP connection as a flow of 362 traffic matching the tuple . Note that a UDP 364 connection consists of unidirectional traffic flow between a pair of 365 hosts, or between a host and the receivers of a multicast group. UDP 366 applications SHOULD assign each connection to a unique flow, and 367 hence SHOULD assign each connection a unique Flow Label value. One 368 exception is where multiple application data streams are multiplexed 369 onto the same address/port pairs. In this case UDP applications MUST 370 assign application data streams to unique flows (as appropriate for 371 the intended QoS or other handling), and MUST use application-layer 372 demultiplexing to associate incoming data streams with flows. 373 Maintenance of INCOMING_FLOW_ID and OUTGOING_FLOW_ID values for each 374 flow MUST be provided by the application. Note that an alternative 375 to multiplexing multiple application data streams onto the same 376 address/port pair is to utilize different source and/or destination 377 port values for each data stream. 379 There is no standard sockets API for either setting the Flow Label 380 value in outgoing packets, nor retrieving it in incoming packets 381 [RFC3493][RFC3542]. There is also no standard sockets API for 382 specifying that a non-zero Flow Label value be used in outgoing 383 packets. Therefore the requirements above cannot be satisfied, 384 except where a non-standard API is available, or the functionality is 385 provided automatically within the UDP/IP stack. It would be 386 worthwhile to define a standard sockets API for Flow Label 387 management. 389 One application where the use of the Flow Label as a nonce might be 390 beneficial is in protection against DNS cache poisoning attacks 391 [I-D.weaver-dnsext-comprehensive-resolver]. If DNS clients assign 392 each DNS transaction to a unique flow, and if DNS servers sends 393 responses with an outgoing Flow Label value equal to the incoming 394 Flow Label value received in the request, then the client can 395 validate with high-probability that the request was generated by the 396 targeted server, since the UDP source port, DNS transaction ID, and 397 Flow Label provide approximately 51 bits of entropy. 399 Use of the Flow Label with UDP-Lite will be discussed in a subsequent 400 revision of this document. 402 6. SCTP Considerations 404 Use of the Flow Label with SCTP will be discussed in a subsequent 405 revision of this document. 407 7. DCCP Considerations 409 Use of the Flow Label with DCCP will be discussed in a subsequent 410 revision of this document. 412 8. RTP Considerations 414 Use of the Flow Label with RTP applications will be discussed in a 415 subsequent revision of this document. 417 9. Acknowledgements 419 [McGann05] proves that the concept of using the Flow Label as a 420 transport-layer nonce pre-dates this document (although the author 421 only discovered this paper after the writing of this document 422 commenced). If others are aware of when and where this concept might 423 have been discussed previously, please contact the author. 425 This document was produced using the xml2rfc tool [RFC2629]. 427 10. IANA Considerations 429 This memo includes no request to IANA. 431 11. Security Considerations 433 All drafts are required to have a security considerations section. 435 12. References 437 12.1. Normative References 439 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 440 August 1980. 442 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 443 RFC 793, September 1981. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 449 RFC 1948, May 1996. 451 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 452 (IPv6) Specification", RFC 2460, December 1998. 454 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 455 Jacobson, "RTP: A Transport Protocol for Real-Time 456 Applications", STD 64, RFC 3550, July 2003. 458 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 459 "IPv6 Flow Label Specification", RFC 3697, March 2004. 461 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 462 G. Fairhurst, "The Lightweight User Datagram Protocol 463 (UDP-Lite)", RFC 3828, July 2004. 465 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 466 Requirements for Security", BCP 106, RFC 4086, June 2005. 468 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 469 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 471 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 472 Message Protocol (ICMPv6) for the Internet Protocol 473 Version 6 (IPv6) Specification", RFC 4443, March 2006. 475 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 476 RFC 4960, September 2007. 478 12.2. Informative References 480 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 481 Signature Option", RFC 2385, August 1998. 483 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 484 June 1999. 486 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 487 Stevens, "Basic Socket Interface Extensions for IPv6", 488 RFC 3493, February 2003. 490 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 491 "Advanced Sockets Application Program Interface (API) for 492 IPv6", RFC 3542, May 2003. 494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 495 Internet Protocol", RFC 4301, December 2005. 497 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 498 RFC 4953, July 2007. 500 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 501 Mitigations", RFC 4987, August 2007. 503 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 504 Pignataro, "The Generalized TTL Security Mechanism 505 (GTSM)", RFC 5082, October 2007. 507 [I-D.ietf-tcpm-icmp-attacks] 508 Gont, F., "ICMP attacks against TCP", 509 draft-ietf-tcpm-icmp-attacks-03 (work in progress), 510 March 2008. 512 [I-D.ietf-tcpm-tcpsecure] 513 Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 514 Robustness to Blind In-Window Attacks", 515 draft-ietf-tcpm-tcpsecure-10 (work in progress), 516 July 2008. 518 [I-D.ietf-tsvwg-port-randomization] 519 Larsen, M. and F. Gont, "Port Randomization", 520 draft-ietf-tsvwg-port-randomization-02 (work in progress), 521 August 2008. 523 [I-D.ietf-tcpm-tcp-auth-opt] 524 Touch, J., Mankin, A., and R. Bonica, "The TCP 525 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-01 526 (work in progress), July 2008. 528 [I-D.weaver-dnsext-comprehensive-resolver] 529 Weaver, N., "Comprehensive DNS Resolver Defenses Against 530 Cache Poisoning", 531 draft-weaver-dnsext-comprehensive-resolver-00 (work in 532 progress), September 2008. 534 [McGann05] 535 McGann, O. and D. Malone, "Flow Label Filtering 536 Feasibility", European Conference on Computer Network 537 Defence, December 2005. 539 Author's Address 541 Steven Blake 542 Extreme Networks 543 Pamlico Building One, Suite 100 544 3306/08 E. NC Hwy 54 545 RTP, NC 27709 546 USA 548 Phone: +1 919 884 3211 549 Email: sblake@extremenetworks.com 551 Full Copyright Statement 553 Copyright (C) The IETF Trust (2008). 555 This document is subject to the rights, licenses and restrictions 556 contained in BCP 78, and except as set forth therein, the authors 557 retain all their rights. 559 This document and the information contained herein are provided on an 560 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 561 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 562 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 563 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 564 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 567 Intellectual Property 569 The IETF takes no position regarding the validity or scope of any 570 Intellectual Property Rights or other rights that might be claimed to 571 pertain to the implementation or use of the technology described in 572 this document or the extent to which any license under such rights 573 might or might not be available; nor does it represent that it has 574 made any independent effort to identify any such rights. Information 575 on the procedures with respect to rights in RFC documents can be 576 found in BCP 78 and BCP 79. 578 Copies of IPR disclosures made to the IETF Secretariat and any 579 assurances of licenses to be made available, or the result of an 580 attempt made to obtain a general license or permission for the use of 581 such proprietary rights by implementers or users of this 582 specification can be obtained from the IETF on-line IPR repository at 583 http://www.ietf.org/ipr. 585 The IETF invites any interested party to bring to its attention any 586 copyrights, patents or patent applications, or other proprietary 587 rights that may cover technology that may be required to implement 588 this standard. Please address the information to the IETF at 589 ietf-ipr@ietf.org.