idnits 2.17.1 draft-ietf-tcpm-tcp-antispoof-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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.3 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 863. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 879), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document has an RFC 3978 Section 5.3 Publication Limitation clause. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 13, 2005) is 7011 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) == Unused Reference: '14' is defined on line 774, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 799, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 802, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2385 (ref. '4') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 1337 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 793 (ref. '10') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (ref. '11') (Obsoleted by RFC 7323) ** Downref: Normative reference to an Informational RFC: RFC 1810 (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 1263 (ref. '14') -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 2960 (ref. '16') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '19') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '20') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '21') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '23') (Obsoleted by RFC 4306) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-01 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-06 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-02 == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-07 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-14 Summary: 20 errors (**), 0 flaws (~~), 11 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF TCPM WG J. Touch 2 Internet Draft USC/ISI 3 Expires: August 2005 February 13, 2005 5 Defending TCP Against Spoofing Attacks 6 draft-ietf-tcpm-tcp-antispoof-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 This document may only be posted in an Internet-Draft. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 13, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 Recent analysis of potential attacks on core Internet infrastructure 42 indicates an increased vulnerability of TCP connections to spurious 43 resets (RSTs). TCP has always been susceptible to such RST spoof 44 attacks, which were indirectly protected by checking that the RST 45 sequence number was inside the current receive window, as well as via 46 the obfuscation of TCP endpoint and port numbers. For pairs of well- 47 known endpoints often over predictable port pairs, such as BGP or 48 between web servers and well-known large-scale caches, increases in 49 the path bandwidth-delay product of a connection have sufficiently 50 increased the receive window space that off-path third parties can 51 guess a viable RST sequence number. This document addresses this 52 vulnerability, discussing proposed solutions at the transport level 53 and their inherent challenges, as well as existing network level 54 solutions and the feasibility of their deployment. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [1]. 62 Table of Contents 64 1. Introduction...................................................3 65 2. Background.....................................................4 66 2.1. Recent BGP Attacks Using TCP RSTs.........................4 67 2.2. TCP RST Vulnerability.....................................5 68 2.3. What Changed -- the Ever Opening Window...................5 69 3. Proposed solutions.............................................8 70 3.1. Transport Layer Solutions.................................8 71 3.1.1. TCP MD5 Authentication...............................8 72 3.1.2. TCP RST Window Attenuation...........................8 73 3.1.3. TCP Timestamp Authentication.........................9 74 3.1.4. Other TCP Cookies...................................10 75 3.1.5. Other TCP Considerations............................10 76 3.1.6. Other Transport Protocol Solutions..................11 77 3.2. Network Layer (IP) Solutions.............................11 78 4. Issues........................................................12 79 4.1. Transport Layer (e.g., TCP)..............................12 80 4.2. Network Layer (IP).......................................13 81 4.3. Application Layer........................................14 82 4.4. Shim Transport/Application Layer.........................14 83 4.5. Link Layer...............................................14 84 4.6. Conclusion...............................................15 85 5. Security Considerations.......................................15 86 6. Conclusions...................................................16 87 7. Acknowledgments...............................................16 88 8. References....................................................16 89 8.1. Normative References.....................................16 90 8.2. Informative References...................................18 91 Author's Addresses...............................................18 92 Intellectual Property Statement..................................19 93 Disclaimer of Validity...........................................19 94 Copyright Statement..............................................19 95 Acknowledgment...................................................19 97 1. Introduction 99 Analysis of the Internet infrastructure has been recently 100 demonstrated new version of a vulnerability in BGP connections 101 between core routers using an attack known for nearly six years 102 [3][4]. These connections, typically using TCP, can be susceptible 103 to off-path (non man-in-the-middle) third-party reset (RST) segments, 104 which terminate the TCP connection. BGP routers react to a 105 terminated TCP connection in various ways, ranging from restarting 106 the connection to deciding that the other router is unreachable and 107 thus flushing the BGP routes. This sort of attack affects other 108 protocols besides BGP, involving any long-lived connection between 109 well-known endpoints. The impact on Internet infrastructure can be 110 substantial (esp. for the BGP case), and warrants immediate 111 attention. 113 TCP, like many other protocols, can be susceptible to these off-path 114 third-party attacks. Such attacks rely on the increase of commodity 115 platforms supporting public access to previously privileged 116 resources, such as root-level access. Given such access, it is 117 trivial for anyone to generate a packet with any header desired. 119 This, coupled with the lack of sufficient ingress filtering to drop 120 such spoofed traffic, can increase the potential for off-path third- 121 party spoofing attacks. Proposed solutions include the deployment of 122 existing Internet network and transport security as well as 123 modifications to transport protocols that reduce its vulnerability to 124 generated attacks. 126 One way to defeat spoofing is to validate the segments of a 127 connection, either at the transport level or the network level. TCP 128 with MD5 extensions provides this authentication at the transport 129 level, and IPsec provides authentication at the network level. In 130 both cases their deployment overhead may be prohibitive, e.g., it may 131 not feasible for public services, such as web servers, to be 132 configured with the appropriate certificate authorities of large 133 numbers of peers (for IPsec using IKE), or shared secrets (for IPsec 134 in shared-secret mode, or TCP/MD5), because many clients may need to 135 be configured rapidly without external assistance. Services from 136 public web servers connecting to large-scale caches to BGP with 137 larger numbers of peers can experience this challege. 139 The remainder of this document outlines the recent attack scenario in 140 detail and describes and compares a variety of solutions, including 141 existing solutions based on TCP/MD5 and IPsec, as well as recently 142 proposed solutions, including modifications to TCP's RST processing 143 [24], modifications to TCP's timestamp processing [5], and 144 modifications to IPsec and TCP/MD5 keying [6]. 146 2. Background 148 The recent analysis of potential attacks on BGP has again raised the 149 issue of TCP's vulnerability to off-path third-party spoofing attacks 150 [3]. A variety of such attacks have been known for several years, 151 including sending RSTs, SYNs, and even ACKs in an attempt to affect 152 an existing connection or to load down servers. Overall, such 153 attacks are countered by the use of some form of authentication at 154 the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or 155 other layers. TCP already includes a weak form of such 156 authentication in its check of segment sequence numbers against the 157 current receiver window. Increases in the bandwidth-delay product 158 for certain long connections have sufficiently weakened this type of 159 weak authentication in recent weeks, rendering it moot. 161 2.1. Recent BGP Attacks Using TCP RSTs 163 BGP represents a particular vulnerability to spoofing attacks. Most 164 TCP connections are protected by multiple levels of obfuscation 165 except at the endpoints of the connection: 167 o Both endpoint addresses are usually not well-known; although server 168 addresses are advertised, clients are somewhat anonymous. 170 o Both port numbers are usually not well-known; the server's usually 171 is advertised (representing the service), but the client's is 172 typically sufficiently unpredictable to an off-path third-party. 174 o Valid sequence number space is not well-known. 176 o Connections are relatively short-lived and valid sequence space 177 changes, so any guess of the above information is unlikely to be 178 useful. 180 BGP represents an exception to the above criteria (though not the 181 only case). Both endpoints are well-known, notably as part of an AS 182 path. The destination port is typically fixed to indicate the BGP 183 service. The source port used by a BGP router is sometimes fixed and 184 advertised to enable firewall configuration; even when not fixed, 185 there are only 65,384 valid source ports which may be exhaustively 186 attacked. Connections are long-lived, and as noted before some BGP 187 implementations interpret successive TCP connection failures as 188 routing failures, discarding the corresponding routing information. 189 As importantly and as will be shown below, the valid sequence number 190 space once thought to provide some protection has been rendered 191 useless by increasing congestion window sizes. 193 2.2. TCP RST Vulnerability 195 TCP has a known vulnerability to third-party spoofed segments. SYN 196 flooding consumes server resources in half-open connections, 197 affecting the server's ability to open new connections. ACK spoofing 198 can cause connections to transmit too much data too quickly, creating 199 network congestion and segment loss, causing connections to slow to a 200 crawl. In the most recent attacks on BGP, RSTs cause connections to 201 be dropped. As noted earlier, some BGP implementations interpret TCP 202 connection termination, or a series of such failures, as a network 203 failure. This causes routers to drop the BGP routing information 204 already exchanged, in addition to inhibiting their ongoing exchanges. 205 The result can affect routing paths throughout the Internet. 207 The dangerous effects of RSTs on TCP have been known for many years, 208 even when used by the legitimate endpoints of a connection. TCP RSTs 209 cause the receiver to drop all connection state; because the source 210 is not required to maintain a TIME_WAIT state, such a RST can cause 211 premature reuse of address/port pairs, potentially allowing segments 212 from a previous connection to contaminate the data of a new 213 connection, known as TIME_WAIT assassination [7]. In this case, 214 assassination occurs inadvertently as the result of duplicate 215 segments from a legitimate source, and can be avoided by blocking RST 216 processing while in TIME_WAIT. However, assassination can be useful 217 to deliberately reduce the state held at servers; this requires that 218 the source of the RSTs go into TIME_WAIT state to avoid such hazards, 219 and that RSTs are not blocked in the TIME_WAIT state [8]. 221 Firewalls and load balancers, so-called 'middleboxes', sometimes emit 222 RSTs on behalf of transited connections to optimize server 223 performance [9]. This is effectively a 'man in the middle' RST 224 attack in which the RSTs are sent for benign or beneficial intent. 225 There are numerous hazards with such use of RSTs, outlined in that 226 RFC. 228 2.3. What Changed -- the Ever Opening Window 230 RSTs represent a hazard to TCP, especially when completely unchecked. 231 Fortunately, there are a number of obfuscation mechanisms that make 232 it difficult for off-path third parties to forge (spoof) valid RSTs, 233 as noted earlier. We have already shown it is easy to learn both 234 endpoint addresses and ports for some protocols, notably BGP. The 235 final obfuscation is the segment sequence number. 237 TCP segments include a sequence number which enables out-of-order 238 receiver processing, as well as duplicate detection. The sequence 239 number space is also used to manage congestion, and indicates the 240 index of the next byte to be transmitted or received. For RSTs, this 241 is relevant because legitimate RSTs use the next sequence number in 242 the transmitter window, and the receiver checks that incoming RSTs 243 have a sequence number in the expected receive window. Such 244 processing is intended to eliminate duplicate segments (somewhat moot 245 for RSTs, though), and to drop RSTs which were part of previous 246 connections. 248 TCP uses two window mechanisms, a primary mechanism which uses a 249 space of 32 bits, and a secondary mechanism which scales this window 250 [10][11]. The valid receive window is a fraction, not to exceed 251 approximately half, of this space, or ~2,000,000,000. Under typical 252 use, the majority of TCP connections open to a very small fraction of 253 this space, e.g., 10,000-60,000(approximately 5-100 segments). On a 254 low-loss path, the window should open to around the path bandwidth- 255 delay product, including buffering delays (assume 1 packet/hop). 256 Many paths in the Internet have end-to-end bandwidths of under 1 257 Mbps, latencies under 100ms, and are under 15 hops, resulting in 258 fairly small windows as above (under 35,000 bytes). Under these 259 conditions, and further assuming that the initial sequence number is 260 suitably (pseudo-randomly) chosen, a valid guessed sequence number 261 would have odds of 1 in 57,000. Put differently, a blind (non man- 262 in-the-middle) attacker would need to send 57,000 RSTs with suitably 263 spaced sequence number guesses to successfully reset a connection. 264 At 1 Mbps, 57,000 (40 byte) RSTs would take over 50 minutes to 265 transmit, and, as noted earlier, most current connections are fairly 266 brief by comparison. 268 Recent use of high bandwidth paths of 10 Gbps and result in 269 bandwidth-delay products over 125 MB - approximately 1/10 of TCP's 270 overall window size excluding scale, assuming the receiver allocates 271 sufficient buffering (to be discussed later). Even under networks 272 that are ten times slower (1 Gbps), the active receiver window covers 273 1/100th of the overall window size. At these speeds, it takes only 274 10-100 packets, or under 32 microseconds, to correctly guess a valid 275 sequence number and kill a connection. A table of corresponding 276 exposure to various amounts of RSTs is shown below, for various line 277 rates, assuming the more conventional 100ms latencies (though even 278 100ms is large for BGP cases): 280 BW BW*delay RSTs needed Time needed 281 ------------------------------------------------------------ 282 10 Gbps 125 MB 35 1 us (microsecond) 283 1 Gbps 12.5 MB 344 110 us 284 100 Mbps 1.25 MB 3,436 10 ms (millisecond) 285 10 Mbps 0.125 MB 34,360 1 second 286 1 Mbps 0.0125 MB 343,598 2 minutes 287 100 Kbps 0.00125 MB 3,435,974 3 hours 289 Figure 1: Time needed to kill a connection 291 This table demonstrates that the effect of bandwidth on the 292 vulnerability is squared; for every increase in bandwidth, there is a 293 linear decrease in the number of sequence number guesses needed, as 294 well as a linear decrease in the time needed to send a set of 295 guesses. Notably, as inter-router link bandwidths approach 1 Mbps, 296 an 'exhaustive' attack becomes practical. Checking that the RST 297 sequence number is somewhere in the valid window (bw*delay) out of 298 the overall window (2^32) is an insufficient obfuscation. 300 Note that this table makes a number of assumptions: 302 1. the overall bandwidth-delay product is relatively fixed 304 2. traffic losses are negligible (insufficient to affect the 306 3. congestion window over most of the connection) 308 4. the receive socket buffers do not limiting the receive window 310 5. the attack bandwidth is similar to the end-to-end path bandwidth 312 Of these assumptions, the last two are more notable. The issue of 313 receive socket buffers will be addressed later. The issue of the 314 attack bandwidth is considered reasonable as follows: 316 1. RSTs are substantially easier to send than data; they can be 317 precomputed and they are smaller than data packets (40 bytes). 319 2. although susceptible connections use somewhat less ubiquitous 320 high-bandwidth paths, the attack may be distributed, at which 321 point only the ingress link of the attack is the primary 322 limitation 324 3. for the purposes of the above table, we assume that the ingress at 325 the attack has the same bandwidth as the path, as an approximation 327 The previous sections discussed the nature of the recent attacks on 328 BGP due to the vulnerability of TCP to RST spoofing attacks, due 329 largely to recent increases in the fraction of the TCP window space 330 in use for a single, long-lived connection. 332 3. Proposed solutions 334 TCP currently authenticates received RSTs using the address and port 335 pair numbers, and checks that the sequence number is inside the valid 336 receiver window. The previous section demonstrated how TCP has 337 become more vulnerable to RST spoofing attacks due to the increases 338 in the receive window size. There are a number of current and 339 proposed solutions to this vulnerability, all attempting to increase 340 the authentication of received RSTs. 342 3.1. Transport Layer Solutions 344 The transport layer represents the last place that segments can be 345 authenticated before they affect connection management. TCP has a 346 variety of current and proposed mechanisms to increase the 347 authentication of segments, protecting against both off-path third- 348 party spoofs and man-in-the-middle attacks. SCTP also has mechanisms 349 to authenticate segments. 351 3.1.1. TCP MD5 Authentication 353 An extension to TCP supporting MD5 authentication was developed 354 around six years ago specifically to authenticate BGP connections 355 (although it can be used for any TCP connection) [4]. The extension 356 relies on a pre-shared secret key to authenticate the entire TCP 357 segment, including the data, TCP header, and TCP pseudo-header 358 (certain fields of the IP header). All segments are protected, 359 including RSTs, to be accepted only when their signature matches. 360 This option, although widely deployed in Internet routers, is 361 considered undeployable for widespread use because the need for pre- 362 shared keys. It further is considered computationally expensive for 363 either hosts or routers due to the overhead of MD5 [12][13]. 365 3.1.2. TCP RST Window Attenuation 367 A recent proposal extends TCP to further constrain received RST to 368 match the expected next sequence number [24]. This restores TCP's 369 resistance to spurious RSTs, effectively limiting the receive window 370 for RSTs to a single number. As a result, an attacker would need to 371 send 2^32 different packets to correctly guess the sequence number. 372 The extension further modifies the RST receiver to react to 373 incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST 374 source is legitimate, upon receipt of an ACK the closed source would 375 presumably emit a RST with the sequence number matching the ACK, 376 correctly resetting the intended recipient. This modification adds 377 arcs to the TCP state diagram, adding to its complexity and thus 378 potentially affecting its correctness (in contrast to adding MD5 379 signatures, which is orthogonal to the state machine altogether). 380 For example, there may be complications between RSTs of different 381 connections between the same pair of endpoints because RSTs flush the 382 TIME-WAIT (as mentioned earlier). Further, this modifies TCP so that 383 under some circumstances a RST causes a reply, in violation of 384 generally accepted practice, if not gentle recommendation. The 385 advantage to this proposal is that it can be deployed incrementally 386 and has benefit to the endpoint on which it is deployed. 388 A variant of this proposal uses a different value to attenuate the 389 window of viable RSTs. It requires RSTs to carry the initial 390 sequence number rather than the next expected sequence number, i.e., 391 the value negotiated on connection establishment [15]. This proposal 392 has the advantage of using an explicitly negotiated value, but at the 393 cost of changing the behavior of an unmodified endpoint to a 394 currently valid RST. It would thus be more difficult, without 395 additional mechanism, to deploy incrementally. 397 The most obvious other variant of this proposal involves increasing 398 TCP's window space, rather than decreasing the valid range for RSTs, 399 i.e., increasing the sequence space from 32 bits to 64 bits. This 400 has the equivalent effect - the ratio of the valid sequence numbers 401 for any segment to the overall sequence number space is significantly 402 reduced. The use of the larger space, as with current schemes to 403 establish weak authentication using initial sequence numbers (ISNs), 404 is contingent on using suitably random values for the ISN. Such 405 randomness adds additional complexity to TCP both in specification 406 and implementation, and provides only very weak authentication. Such 407 a modification is not obviously backward compatible, and would be 408 thus difficult to deploy. 410 3.1.3. TCP Timestamp Authentication 412 Another way to authenticate TCP segments is to utilize its timestamp 413 option, using the value as a sort of authentication [5]. This 414 requires that the receiver TCP discard values whose timestamp is 415 outside the accepted window, which is derived from the timestamps of 416 other packets from the same connection. This technique uses an 417 existing TCP option, but also requires modified RST processing and 418 may be difficult to deploy incrementally without further 419 modifications. Additionally, the timestamp value may be easier to 420 guess because it is derived from a predictable value. 422 3.1.4. Other TCP Cookies 424 All of the above techniques are variants of cookies, otherwise 425 meaningless data whose value is used to validate the packet. In the 426 case of MD5 checksums, the cookie is computed based on a shared 427 secret. Note that even a signature can be guessed, and presents a 1 428 in 2^(signature length) probability of attack. The primary 429 difference is that MD5 signatures are effectively one-time cookies, 430 not predictable based on man-in-the-middle snooping, because they are 431 dependent on packet data and thus do not repeat. Window attenuation 432 sequence numbers can be guessed by snooping the sequence number of 433 current packets, and timestamps can may be guessed even more 434 remotely. These variants of cookies are similar in spirit to TCP SYN 435 cookies, again patching a vulnerability to off-path third-party 436 spoofing attacks based on a (fairly weak, excepting MD5) form of 437 authentication. Another form of cookie is the source port itself, 438 which can be randomized but provides only 16 bits of protection 439 (65,000 combinations), which may be exhaustively attacked. This can 440 be combined with destination port randomization as well, but that 441 would require a separate coordination mechanism (so both parties know 442 which ports to use), which is equivalent to (and as infeasible for 443 large-scale deployments as) exchanging a shared secret. 445 3.1.5. Other TCP Considerations 447 The analysis of the potential for RST spoofing above assumes that the 448 receive window opens to the maximum extent suggested by the 449 bandwidth-delay product of the end-to-end path, and that the window 450 opens to an appreciable fraction of the overall sequence number 451 space. As noted earlier, for most common cases, connections are too 452 brief or over bandwidths too low to for such a large window to occur. 453 Expanding TCP's sequence number space is a direct way to further 454 avoid such vulnerability, even for long connections over emerging 455 bandwidths. 457 Finally, it is often sufficient for the endpoint to limit the receive 458 window in other ways, notably using 'socket options'. If the receive 459 socket buffer is limited, e.g., to the ubiquitous default of 65KB, 460 the receive window cannot grow to vulnerable sizes even for very long 461 connections over very high bandwidths. The consequence is lower 462 sustained throughput, where only one window's worth of data per round 463 trip time (RTT) is exchanged. Although this will keep the connection 464 open longer, it also reduces the receive window; for long-lived 465 connections with continuous sourced data, this may continue to 466 present an attack opportunity, albeit a sparse and slow-moving 467 target. For the most recent case where BGP data is being exchanged 468 between Internet routers, the data is bursty and the aggregate 469 traffic is small (i.e., unlikely to cover a substantial portion of 470 the sequence space, even if long-lived), so is difficult to consider 471 where smaller receive buffers would not sufficiently address the 472 immediate problem. 474 3.1.6. Other Transport Protocol Solutions 476 Segment authentication has been addressed at the transport layer in 477 other protocols. Both SCTP and DCCP* include cookies for connection 478 establishment and uses them to authenticate a variety of other 479 control messages [16][25]. The inclusion of such mechanism at the 480 transport protocol, although emerging as standard practice, 481 unnecessarily complicates the design and implementation of new 482 protocols. As new attacks are discovered (SYN floods, RSTs, etc.), 483 each protocol must be modified individually to compensate. A network 484 solution may be more appropriate and efficient. 486 *[AUTH - DCCP may be removing cookies from the spec for the 487 redundancies discussed above, because the use of cookies at the 488 transport layer primarily supports dynamic multihoming (a design goal 489 of SCTP, but not DCCP) rather than security.] 491 3.2. Network Layer (IP) Solutions 493 TCP is susceptible to RSTs, but also to other spoofing and man-in- 494 the-middle attacks, including SYN attacks. Other transport 495 protocols, such as UDP and RTP are equally susceptible. Although 496 emerging transport protocols attempt to defeat such attacks at the 497 transport layer, such attacks take advantage of network layer 498 identity spoofing. The packet is coming from an endpoint who is 499 spoofing another endpoint, either upstream or somewhere else in the 500 Internet. IPsec was designed specifically to establish and enforce 501 authentication of a packet's source and contents, to most directly 502 and explicitly addresses this security vulnerability. 504 The larger problem with IPsec is that of CA key distribution and use. 505 IPsec is often cumbersome, and has only recently been supported in 506 many end-system operating systems. More importantly, it relies on 507 signed X.509 certificates to establish and exchange keying 508 information (e.g., via IKE). These present challenges when using 509 IPsec to secure traffic to a well-known server, whose clients may not 510 support IPsec or may not have registered with a previously-known 511 certificate authority (CA). 513 4. Issues 515 There are a number of existing and proposed solutions addressing the 516 vulnerability of transport protocols in general, and TCP in specific, 517 to off-path third-party spoofing attacks. As shown, these operate at 518 the transport or network layer. Transport solutions require separate 519 modification of each transport protocol, addressing network identity 520 spoofing separately in the context of each transport association. 521 Network solutions are computationally intensive and require pervasive 522 registration of certificate authorities with every possible endpoint. 523 This section explains these observations further. 525 4.1. Transport Layer (e.g., TCP) 527 Transport solutions rely on shared cookies to authenticate segments, 528 including data, transport header, and even pseudo-header (e.g., fixed 529 portions of the outer IP header in TCP). Because the Internet relies 530 on stateless network protocols, it makes sense to rely on state 531 establishment and maintenance available in some transport layers not 532 only for the connection but for authentication state. Three-way 533 handshakes and heartbeats can be used to negotiate authentication 534 state in conjunction with connection parameters, which can be stored 535 with connection state easily. 537 As noted earlier, transport layer solutions require separate 538 modification of all transport protocols to include authentication. 539 Not all transport layers support negotiated endpoint state (e.g., 540 UDP), and legacy protocols have been notoriously difficult to safely 541 augment. Not all authentication solutions are created equal either, 542 and relying on a variety of transport solutions exposes end-systems 543 to increased potential for incorrectly specified or implemented 544 solutions. Transport authentication has often been developed piece- 545 wise, in response to specific attacks, e.g., SYN cookies and RST 546 window attenuation [17][24]. 548 Transport layer solutions are not only per-protocol, but often per- 549 connection. Each connection needs to negotiate and maintain 550 authentication state separately. Overhead is not amortized over 551 multiple connections - this includes overheads in packet exchanges, 552 design complexity, and implementation complexity. Finally, because 553 the authentication happens later in packet processing than is 554 required, additional endpoint resources may be needlessly consumed, 555 e.g., in demultiplexing received packets, indexing connection 556 identifiers, etc., only to be dropped later at the transport layer. 558 4.2. Network Layer (IP) 560 A network layer solution avoids the hazards of multiple transport 561 variants, using a single shared endpoint authentication mechanism 562 early in receiver packet processing to discard unauthenticated 563 packets quickly. Network solutions protect all transport protocols, 564 including both legacy and emerging protocols, and reduce the 565 complexity of these protocols as well. A shared solution also 566 reduces protocol overhead, and decouples the management (and 567 refreshing) of authentication state from that of individual transport 568 connections. Finally, a network layer solution protects not only the 569 transport layer but the network layer as well, e.g., from ICMP, IGMP, 570 etc., spoofing attacks. 572 The ubiquitous protocol for network layer authentication is IPsec 573 [18][26]. IPsec specifies the overall architecture, including header 574 authentication (AH) [19][27] and encapsulation (ESP) modes [20]. AH 575 authenticates both the IP header and IP data, whereas ESP 576 authenticates only the IP data (e.g., transport header and payload). 577 AH is deprecated since ESP is more efficient and the SPI includes 578 sufficient information to verify the IP header anyway. These two 579 modes describe the security applied to individual packets within the 580 IPsec system; key exchange and management is performed either out-of- 581 band (via pre-shared keys) or by an automated key exchange protocol 582 IKE [21][28]. 584 IPsec already provides authentication of an IP header and its data 585 contents sufficient to defeat both man-in-the-middle and off-path 586 third-party spoofing attacks. IKE can configure authentication 587 between two endpoints on a per-endpoint, per-protocol, or per- 588 connection basis, as desired. IKE also can perform automatic 589 periodic re-keying, further defeating crypto-analysis based on 590 snooping (clandestine data collection). The use of IPsec is already 591 commonly strongly recommended for protected infrastructure. 593 IPsec is not appropriate for many deployments. It is computationally 594 intensive both in key management and individual packet authentication 595 [12]. As importantly, IKE is not anonymous; keys can be exchanged 596 between parties only if they trust each others' X.509 certificates or 597 pre-share a key. These certificates provide identification (the 598 other party knows who you are) only where the certificates themselves 599 are signed by certificate authorities (CAs) that both parties already 600 trust. To a large extent, the CAs themselves are the pre-shared keys 601 which help IKE establish security association keys, which are then 602 used in the authentication algorithms. 604 IPsec, although widely available both in commercial routers and 605 commodity end-systems, is not often utilized except between parties 606 that already have a preexisting relationship (employee/employer, 607 between two ISPs, etc.) Servers to anonymous clients (e.g., customer/ 608 business) or more open services (e.g., BGP, where routers may large 609 numbers of peers) are unmanageable, due to the breadth and flux of 610 CAs. New endpoints cannot establish IPsec associations with such 611 servers unless their certificate is signed by a CA already trusted by 612 the server. Different servers - even within the same overall system 613 (e.g., BGP) - often cannot or will not trust overlapping subsets of 614 CAs in general. 616 4.3. Application Layer 618 There are a number of application layer authentication mechanisms, 619 often implicit within end-to-end encryption. Application-layer 620 security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) 621 provides the ultimate protection of application data from all 622 intermediaries, including network routers as well as exposure at 623 other layers in the end-systems. This is the only way to ultimately 624 protect the application data. 626 Application authentication cannot protect either the network or 627 transport protocols from spoofing attacks, however. Spoofed packets 628 interfere with network processing or reset transport connections 629 before the application checks the data. Authentication needs to 630 winnow these packets and drop them before they interfere at these 631 lower layers. 633 4.4. Shim Transport/Application Layer 635 Security can also be provided over the transport layer but below the 636 application layer, in a kind of 'shim' protocol, such as SSL or TLS. 637 These protocols provide data protection for a variety of applications 638 over a single, legacy transport protocol, such as SSL/TCP for HTTPS. 639 Unfortunately, as with application authentication, they do not 640 protect the transport layer against spoofing attacks. 642 4.5. Link Layer 644 Link layer security operates separately on each hop of an Internet. 645 Such security can be critical in protecting link resources, such as 646 bandwidth and link management protocols. Protection at this layer 647 cannot suffice for network or transport layers, because it cannot 648 authenticate the endpoint source of a packet. Link authentication 649 ensures only the source of the current link hop where it is examined. 651 4.6. Conclusion 653 The issues raised in this section suggest that there are challenges 654 with all solutions to transport protection from spoofing attacks. 655 This raises the potential need for alternate security levels. While 656 it is already widely recognized that security needs to occur 657 simultaneously at many protocol layers, the also may be utility in 658 supporting a variety of strengths at a single layer. For example, 659 IPsec already supports a variety of algorithms (MD5, SHA, etc. for 660 authentication), but always assumes that: 662 1. the entire body of the packet is secured 664 2. security associations are established only where identity is 665 authenticated by a know certificate authority or other pre-shared 666 key 668 3. both man-in-the-middle and off-path third-party spoofing attacks 669 must be defeated 671 These assumptions are prohibitive, especially in many cases of 672 spoofing attacks. For spoofing, the primary issue is whether packets 673 are coming from the same party the server can reach. Only the IP 674 header is fundamentally in question, so securing the entire packet 675 (1) is computational overkill. It is sufficient to authenticate the 676 other party as "a party you have exchanged packets with", rather than 677 establishing their trusted identity ("Bill" vs. "Bob") as in (2). 678 Finally, many cookie systems use clear-text (unencrypted), fixed 679 cookie values, providing reasonable (1 in 2^{cookie-size}) protection 680 against off-path third-party spoofs, but not addressing man-in-the- 681 middle at all. Such potential solutions are discussed in the ANONsec 682 document, in the BTNS (Better Than Nothing Security) BOF [2][6]. 684 5. Security Considerations 686 This entire document focuses on increasing the security of transport 687 protocols and their resistance to spoofing attacks. Security is 688 addressed throughout. 690 This document describes a number of techniques for defeating spoofing 691 attacks. Those relying on clear-text cookies, either explicit or 692 implicit (e.g., window sequence attenuation) do not protect from man- 693 in-the-middle spoofing attacks, since valid values can be learned 694 from prior traffic. Those relying on true authentication algorithms 695 are stronger, protecting even from man-in-the-middle, because the 696 authentication hash in a single packet approaches the behavior of 697 "one time" cookies. 699 The security of various levels of the protocol stack is addressed. 700 Spoofing attacks are fundamentally identity masquerading, so we 701 believe the most appropriate solutions defeat these at the network 702 layer, where end-to-end identity lies. Some transport protocols 703 subsume endpoint identity information from the network layer (e.g., 704 TCP pseudo-headers), whereas others establish per-connection identity 705 based on exchanged nonces (e.g., SCTP). It is reasonable, if not 706 recommended, to address security at all layers of the protocol stack. 708 6. Conclusions 710 This document describes the details of the recent BGP spoofing 711 attacks involving spurious RSTs which could be used to shutdown TCP 712 connections. It summarizes and discusses a variety of current and 713 proposed solutions at various protocol layers. 715 7. Acknowledgments 717 This document was inspired by discussions on the 718 about the 719 recent spoofed RST attacks on BGP routers, including R. Stewart's 720 draft [15][24]. The analysis of the attack issues, alternate 721 solutions, and the anonymous security proposed solutions were the 722 result of discussions on that list as well as with USC/ISI's T. 723 Faber, A. Falk, G. Finn, and Y. Wang. Ran Atkinson suggested the 724 UDP variant of TCP/MD5, and Paul Goyette suggested using the ISN to 725 seed TCP/MD5. Other improvements are due to the input of various 726 members of the IETF's TCPM WG. 728 8. References 730 (NB: to be reordered and repartitioned) 732 8.1. Normative References 734 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 735 Levels", BCP 14, RFC 2119, March 1997. 737 [2] Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC., 738 http://www.ietf.org/ietf/04nov/btns.txt. 740 [3] "Technical Cyber Security Alert TA04-111A: Vulnerabilities in 741 TCP -- http://www.us-cert.gov/cas/techalerts/TA04-111A.html", 742 April 20 2004. 744 [4] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 745 Signature Option", RFC 2385, August 1998. 747 [5] Poon, K., "Use of TCP timestamp option to defend against blind 748 spoofing attack", (work in progress), June 2004. 750 [6] Touch, J., "ANONsec: Anonymous Security to Defend Against 751 Spoofing Attacks", (work in progress), July 2004. 753 [7] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, 754 May 1992. 756 [8] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 757 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 758 1583, March 1999. 760 [9] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 761 60, RFC 3360, August 2002. 763 [10] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 764 September 1981. 766 [11] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for 767 High Performance", RFC 1323, May 1992. 769 [12] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995. 771 [13] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995 772 77-86., March 1999. 774 [14] O'Malley, S. and L. Peterson, "TCP Extensions Considered 775 Harmful", RFC 1263, October 1991. 777 [15] "IETF TCPM Working Group and mailing list - 778 http://www.ietf.org/html.charters/tcpm-charter.html". 780 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 781 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 782 "Stream Control Transmission Protocol", RFC 2960, October 2000. 784 [17] Bernstein, D., "SYN cookies - http://cr.yp.to/syncookies.html", 785 1997. 787 [18] Kent, S. and R. Atkinson, "Security Architecture for the 788 Internet Protocol", RFC 2401, November 1998. 790 [19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 791 November 1998. 793 [20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 794 (ESP)", RFC 2406, November 1998. 796 [21] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 797 RFC 2409, November 1998. 799 [22] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its 800 Use With IPsec", RFC 2410, November 1998. 802 [23] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 803 Association and Key Management Protocol (ISAKMP)", RFC 2408, 804 November 1998. 806 8.2. Informative References 808 [24] Stewart, R., "Transmission Control Protocol security 809 considerations", draft-ietf-tcpm-tcpsecure-01 (work in 810 progress), June 2004. 812 [25] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 813 draft-ietf-dccp-spec-06 (work in progress), February 2004. 815 [26] Kent, S. and K. Seo, "Security Architecture for the Internet 816 Protocol", draft-ietf-ipsec-rfc2401bis-02 (work in progress), 817 April 2004. 819 [27] Kent, S., "IP Authentication Header", draft-ietf-ipsec- 820 rfc2402bis-07 (work in progress), March 2004. 822 [28] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- 823 ietf-ipsec-ikev2-14 (work in progress), June 2004. 825 Author's Addresses 827 Joe Touch 828 USC/ISI 829 4676 Admiralty Way 830 Marina del Rey, CA 90292-6695 831 U.S.A. 833 Phone: +1 (310) 448-9151 834 Fax: +1 (310) 448-9300 835 Email: touch@isi.edu 836 URI: http://www.isi.edu/touch 838 Intellectual Property Statement 840 The IETF takes no position regarding the validity or scope of any 841 Intellectual Property Rights or other rights that might be claimed to 842 pertain to the implementation or use of the technology described in 843 this document or the extent to which any license under such rights 844 might or might not be available; nor does it represent that it has 845 made any independent effort to identify any such rights. Information 846 on the procedures with respect to rights in RFC documents can be 847 found in BCP 78 and BCP 79. 849 Copies of IPR disclosures made to the IETF Secretariat and any 850 assurances of licenses to be made available, or the result of an 851 attempt made to obtain a general license or permission for the use of 852 such proprietary rights by implementers or users of this 853 specification can be obtained from the IETF on-line IPR repository at 854 http://www.ietf.org/ipr. 856 The IETF invites any interested party to bring to its attention any 857 copyrights, patents or patent applications, or other proprietary 858 rights that may cover technology that may be required to implement 859 this standard. Please address the information to the IETF at 860 ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that 861 any applicable patent or other IPR claims of which I am aware have 862 been disclosed, and any of which I become aware will be disclosed, in 863 accordance with RFC 3668. 865 Disclaimer of Validity 867 This document and the information contained herein are provided on an 868 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 869 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 870 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 871 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 872 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 873 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 875 Copyright Statement 877 Copyright (C) The Internet Society (2004). This document is subject 878 to the rights, licenses and restrictions contained in BCP 78, and 879 except as set forth therein, the authors retain all their rights. 881 Acknowledgment 883 Funding for the RFC Editor function is currently provided by the 884 Internet Society.