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