idnits 2.17.1 draft-ietf-tcpm-tcp-antispoof-06.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, updated by RFC 4748 on line 1304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1294. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2007) is 6265 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2581 (ref. '1') (Obsoleted by RFC 5681) == Outdated reference: A later version (-05) exists of draft-ietf-tcpm-syn-flood-01 -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '15') (Obsoleted by RFC 5082) == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-rfc3682bis-09 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 == Outdated reference: A later version (-09) exists of draft-ietf-tcpm-tcp-soft-errors-03 -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '20') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '23') (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '24') (Obsoleted by RFC 5996) == Outdated reference: A later version (-02) exists of draft-larsen-tsvwg-port-randomization-01 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '35') (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-06 -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '41') (Obsoleted by RFC 4960) == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 14 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 Intended status: Informational February 23, 2007 4 Expires: August 2007 6 Defending TCP Against Spoofing Attacks 7 draft-ietf-tcpm-tcp-antispoof-06.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of 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 August 23, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 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 brute-force generate a 51 viable RST sequence number. The susceptibility to attack increases 52 with the square of the bandwidth, thus presents a significant 53 vulnerability for recent high-speed networks. This document 54 addresses this vulnerability, discussing proposed solutions at the 55 transport level and their inherent challenges, as well as existing 56 network level solutions and the feasibility of their deployment. 57 This document focuses on vulnerabilities due to spoofed TCP segments, 58 and includes a discussion of related ICMP spoofing attacks on TCP 59 connections. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Background.....................................................4 65 2.1. Review of TCP Windows.....................................5 66 2.2. Recent BGP Attacks Using TCP RSTs.........................6 67 2.3. TCP RST Vulnerability.....................................6 68 2.4. What Changed - the Ever Opening Advertised Receive Window.7 69 3. Proposed Solutions and Mitigations............................10 70 3.1. Transport Layer Solutions................................10 71 3.1.1. TCP MD5 Authentication..............................11 72 3.1.2. TCP RST Window Attenuation..........................11 73 3.1.3. TCP Timestamp Authentication........................12 74 3.1.4. Other TCP Cookies...................................13 75 3.1.5. Other TCP Considerations............................13 76 3.1.6. Other Transport Protocol Solutions..................14 77 3.2. Network Layer (IP) Solutions.............................14 78 3.2.1. Address filtering...................................15 79 3.2.2. IPsec...............................................16 80 4. ICMP..........................................................17 81 5. Issues........................................................18 82 5.1. Transport Layer (e.g., TCP)..............................18 83 5.2. Network Layer (IP).......................................19 84 5.3. Application Layer........................................21 85 5.4. Link Layer...............................................21 86 5.5. Issues Discussion........................................22 87 6. Security Considerations.......................................22 88 7. IANA Considerations...........................................23 89 8. Conclusions...................................................23 90 9. Acknowledgments...............................................23 91 10. References...................................................24 92 10.1. Normative References....................................24 93 10.2. Informative References..................................24 94 Author's Addresses...............................................28 95 Intellectual Property Statement..................................28 96 Disclaimer of Validity...........................................28 98 1. Introduction 100 Analysis of the Internet infrastructure has recently demonstrated a 101 new version of a vulnerability in BGP connections between core 102 routers using an attack based on RST spoofing from off-path attackers 103 [9][10][47]. This attack has been known for nearly six years [20]. 104 Such connections, typically using TCP, can be susceptible to off-path 105 third-party reset (RST) segments with forged source addresses 106 (spoofed), which terminate the TCP connection. BGP routers react to 107 a terminated TCP connection in various ways which can amplify the 108 impact of an attack, ranging from restarting the connection to 109 deciding that the other router is unreachable and thus flushing the 110 BGP routes [37]. This sort of attack affects other protocols besides 111 BGP, involving any long-lived connection between well-known 112 endpoints. The impact on the Internet infrastructure can be 113 substantial (esp. for the BGP case), and warrants immediate 114 attention. 116 TCP, like many other protocols, can be susceptible to these off-path 117 third-party spoofing attacks. Such attacks rely on the increase of 118 commodity platforms supporting public access to previously privileged 119 resources, such as system-level (i.e., root) access. Given such 120 access, it is trivial for anyone to generate a packet with any header 121 desired. 123 This, coupled with the lack of sufficient address filtering to drop 124 such spoofed traffic, can increase the potential for off-path third- 125 party spoofing attacks [9][10][47]. Proposed solutions include the 126 deployment of existing Internet network and transport security as 127 well as modifications to transport protocols that reduce its 128 vulnerability to generated attacks [13][15][20][36][46]. 130 One way to defeat spoofing is to validate the segments of a 131 connection, either at the transport level or the network level. TCP 132 with MD5 extensions provides this authentication at the transport 133 level, and IPsec provides authentication at the network level 134 [20][24][27]. In both cases their deployment overhead may be 135 prohibitive, e.g., it may not be feasible for public services, such 136 as web servers, to be configured with the appropriate certificate 137 authorities of large numbers of peers (for IPsec using IKE), or 138 shared secrets (for IPsec in shared-secret mode, or TCP/MD5), because 139 many clients may need to be configured rapidly without external 140 assistance. Services located on public web servers connecting to 141 large-scale caches to BGP with larger numbers of peers can fall into 142 this category. 144 The remainder of this document outlines the recent attack scenario in 145 detail and describes and compares a variety of solutions, including 146 existing solutions based on TCP/MD5 and IPsec, as well as recently 147 proposed solutions, including modifications to TCP's RST processing 148 [36], modifications to TCP's timestamp processing [34], and 149 modifications to IPsec and TCP/MD5 keying [45]. This document 150 focuses on spoofing of TCP segments, although a discussion of related 151 spoofing of ICMP packets based on spoofed TCP contents is also 152 discussed. 154 Note that the description of these attacks is not new; attacks using 155 RSTs on BGP have been known since 1998, and were the reason for the 156 development of TCP/MD5 [20]. The recent attack scenario was first 157 documented by Convery at a NANOG meeting in 2003, but that analysis 158 assumed the entire sequence space (2^32 packets) needed to be covered 159 for an attack to succeed [10]. Watson's more detailed analysis 160 discovered that a single packet anywhere in the current window could 161 succeed at an attack [47]. This document adds the observation that 162 susceptibility to attack goes as the square of bandwidth, due to the 163 coupling between the linear increase in receive window size and 164 linear increase in rate of a potential attack, as well as comparing 165 the variety of more recent proposals, including modifications to TCP, 166 use of IPsec, and use of TCP/MD5 to resist such attacks. 168 2. Background 170 The recent analysis of potential attacks on BGP has again raised the 171 issue of TCP's vulnerability to off-path third-party spoofing attacks 172 [9][10][47]. A variety of such attacks have been known for several 173 years, including sending RSTs, SYNs, and even ACKs in an attempt to 174 affect an existing connection or to load down servers. These attacks 175 often combine external knowledge (e.g., to indicate the IP addresses 176 to attack, the destination port number, and sometimes the ISN) with 177 brute-force capabilities enabled by modern computers and network 178 bandwidths (e.g., to scan all source ports or an entire window 179 space). Overall, such attacks are countered by the use of some form 180 of authentication at the network (e.g., IPsec), transport (e.g., SYN 181 cookies, TCP/MD5), or other layers. TCP already includes a weak form 182 of such authentication in its check of segment sequence numbers 183 against the current receiver window. Increases in the bandwidth- 184 delay product for certain long connections have sufficiently weakened 185 this type of weak authentication to make reliance on it inadvisable. 187 2.1. Review of TCP Windows 189 Before proceeding, it is useful to review the terminology and 190 components of TCP's windowing algorithm. TCP connections have three 191 kinds of windows [1][35]: 193 o Send window (SND.WND): the latest send window size. 195 o Receive window (RCV.WND): the latest advertised receive window 196 size. 198 o Congestion window (CWND): the window determined by congestion 199 feedback that limits how much of RCV.WND can be in-flight in a 200 round trip time. 202 For most modern TCP connections, SND.WND and RCV.WND are the size of 203 the corresponding send and receive socket buffers, and are 204 configurable using socket buffer resizing commands. 206 CWND determines how much data can be in transit in a round trip time, 207 SND.WND determines how much data the sender is willing to store on 208 its side for possible retransmission due to loss, and RCV.WND 209 determines the ability of the receiver to accommodate that loss and 210 reorder received packets. CWND never grows beyond RCV.WND. 212 High bandwidth-delay product networks need CWND to be sufficiently 213 large to accommodate as much data as can be in transit in a round 214 trip time, otherwise their performance will suffer. As a result, it 215 is recommended that users and various automatic programs increase 216 RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay 217 product) [23][38]. 219 As the bandwidth-delay product of the network increases, however, 220 such increases in the advertised receive window can cause increased 221 susceptibility to spoofing attacks, as the remainder of this document 222 shows. This assumes, however, that the receive window size (e.g., 223 via increased receive socket buffer configuration) is increased with 224 the increased bandwidth-delay product; if not, then connection 225 performance will degrade, but susceptibility to spoofing attacks will 226 increase only linearly (with the rate at which the attacker can send 227 spoofed packets), not as the square of the bandwidth. Note that 228 either increase depends on the receive window itself, and is 229 independent of the congestion state or amount of data transmitted. 231 2.2. Recent BGP Attacks Using TCP RSTs 233 BGP represents a particular vulnerability to spoofing attacks because 234 it uses TCP connectivity to infer routability, so losing a TCP 235 connection with a BGP peer can result in the flushing of routes to 236 that peer [37]. 238 Until six years ago, such connections were assumed difficult to 239 attack because they were described by a few comparatively obscure 240 parameters [20]. Most TCP connections are protected by multiple 241 levels of obfuscation except at the endpoints of the connection: 243 o Both endpoint addresses are usually not well-known; although 244 server addresses are advertised, clients are somewhat anonymous. 246 o Both port numbers are usually not well-known; the server's usually 247 is advertised (representing the service), but the client's is 248 typically sufficiently unpredictable to an off-path third-party. 250 o Valid sequence number space is not well-known. 252 o Connections are relatively short-lived and valid sequence space 253 changes, so any attempt to guess (e.g., by external knowledge or 254 brute force) the above information is unlikely to be useful. 256 BGP represents an exception to the above criteria (though not the 257 only case). Both endpoints can be well-known, or guessed using hints 258 from part of an AS path. The destination port is typically fixed to 259 indicate the BGP service. The source port used by a BGP router is 260 sometimes fixed and advertised to enable firewall configuration; even 261 when not fixed, there are only approximately 65,000 valid source 262 ports which may be exhaustively attacked. Connections are long- 263 lived, and as noted before some BGP implementations interpret 264 successive TCP connection failures as routing failures, discarding 265 the corresponding routing information. In addition, the valid 266 sequence number space once thought to provide some protection has 267 been significantly weakened by increasing advertised receive window 268 sizes. 270 2.3. TCP RST Vulnerability 272 TCP has a known vulnerability to third-party spoofed segments. SYN 273 flooding consumes server resources in half-open connections, 274 affecting the server's ability to open new connections [4][11]. ACK 275 spoofing can cause connections to transmit too much data too quickly, 276 creating network congestion and segment loss, causing connections to 277 slow to a crawl. In the most recent attacks on BGP, RSTs cause 278 connections to be dropped. As noted earlier, some BGP 279 implementations interpret TCP connection termination, or a series of 280 such failures, as a network failure [37]. This causes routers to 281 drop the BGP routing information already exchanged, in addition to 282 inhibiting their ongoing exchanges, thus amplifying the impact of the 283 attack. The result can affect routing paths throughout the Internet. 285 The dangerous effects of RSTs on TCP have been known for many years, 286 even when used by the legitimate endpoints of a connection. TCP RSTs 287 cause the receiver to drop all connection state; because the source 288 is not required to maintain a TIME_WAIT state, such a RST can cause 289 premature reuse of address/port pairs, potentially allowing segments 290 from a previous connection to contaminate the data of a new 291 connection, known as TIME_WAIT assassination [8]. In this case, 292 assassination occurs inadvertently as the result of duplicate 293 segments from a legitimate source, and can be avoided by blocking RST 294 processing while in TIME_WAIT. However, assassination can be useful 295 to deliberately reduce the state held at servers; this requires that 296 the source of the RSTs go into TIME_WAIT state to avoid such hazards, 297 and that RSTs are not blocked in the TIME_WAIT state [12]. 299 Firewalls and load balancers, so-called 'middleboxes', sometimes emit 300 RSTs on behalf of transited connections to optimize server 301 performance, as noted in RFC 3360 [14]. This is effectively an on- 302 path RST attack in which the RSTs are sent for benign or beneficial 303 intent. There are numerous hazards with such use of RSTs, outlined 304 in that RFC. 306 2.4. What Changed - the Ever Opening Advertised Receive Window 308 RSTs represent a hazard to TCP, especially when completely 309 unvalidated. Fortunately, there are a number of obfuscation 310 mechanisms that make it difficult for off-path third parties to forge 311 (spoof) valid RSTs, as noted earlier. We have already shown it is 312 easy to learn both endpoint addresses and ports for some protocols, 313 notably BGP. The final obfuscation is the segment sequence number. 315 TCP segments include a sequence number which enables out-of-order 316 receiver processing as well as duplicate detection. The sequence 317 number space is also used to manage congestion, and indicates the 318 index of the next byte to be transmitted or received. For RSTs, this 319 is relevant because legitimate RSTs use the next sequence number in 320 the transmitter window, and the receiver checks that incoming RSTs 321 have a sequence number in the expected receive window. Such 322 processing is intended to eliminate duplicate segments (somewhat moot 323 for RSTs, though), and to drop RSTs which were part of previous 324 connections. 326 TCP uses two window mechanisms, a primary mechanism which uses a 327 space of 32 bits, and a secondary mechanism which scales this window 328 [23][35]. The valid advertised receive window is a fraction, not to 329 exceed approximately half, of this space, or ~2 billion (2 * 10^9, 330 i.e., 2E9 or 2 U.S. billion). Under typical configurations, the 331 majority of TCP connections open to a very small fraction of this 332 space, e.g., 10,000-60,000(approximately 5-100 segments). This is 333 because the advertised receive window typically matches the receive 334 socket buffer size. It is recommended that this buffer be tuned to 335 match the needs of the connection, either manually or by automatic 336 external means [38]. 338 On a low-loss path, the advertised receive window should be 339 configured to match the path bandwidth-delay product, including 340 buffering delays (assume 1 packet/hop) [38]. Many paths in the 341 Internet have end-to-end bandwidths of under 1 Mbps, latencies under 342 100ms, and are under 15 hops, resulting in fairly small advertised 343 receive windows as above (under 35,000 bytes). Under these 344 conditions, and further assuming that the initial sequence number is 345 suitably (pseudo-randomly) chosen, a valid guessed sequence number 346 would have odds of 1 in 57,000 of falling within the advertised 347 receive window. Put differently, a blind (i.e., off-path) attacker 348 would need to send 57,000 RSTs with suitably spaced sequence number 349 guesses to successfully reset a connection. At 1 Mbps, 57,000 (40 350 byte) RSTs would take only 20 seconds to transmit, but this presumes 351 that both IP addresses and both ports are known. Absent knowledge of 352 the source port, an off-path spoofer would need to try at least the 353 entire range of 49152-65535, or 16,384 different ports, resulting in 354 an attack that would take over 91 hours. Because most TCP 355 connections are comparatively short-lived, even this moderate 356 variation in the source port is sufficient for such environments, 357 although further port randomization may be recommended [29]. 359 Recent use of high bandwidth paths of 10 Gbps and higher results in 360 bandwidth-delay products over 125 MB - approximately 1/10 of TCP's 361 overall maximum advertised receive window size (i.e., assuming the 362 receive socket buffers are increased as much as possible) excluding 363 scale, assuming the receiver allocates sufficient buffering (as 364 discussed in Sec. 2). Even under networks that are ten times slower 365 (1 Gbps), the active advertised receive window covers 1/100th of the 366 overall window size. At these speeds, it takes only 10-100 packets, 367 or less than 32 microseconds, to correctly guess a valid sequence 368 number and kill a connection. A table of corresponding exposure to 369 various amounts of RSTs is shown below, for various line rates, 370 assuming the more conventional 100ms latencies (though even 100ms is 371 large for BGP cases): 373 BW BW*delay RSTs needed Time needed 374 ------------------------------------------------------------ 375 10 Gbps 125 MB 35 1 us (microsecond) 376 1 Gbps 12.5 MB 344 110 us 377 100 Mbps 1.25 MB 3,436 10 ms (millisecond) 378 10 Mbps 0.125 MB 34,360 1 second 379 1 Mbps 0.0125 MB 343,598 2 minutes 380 100 Kbps 0.00125 MB 3,435,974 3 hours 382 Figure 1 Time needed to kill a connection 384 This table demonstrates that the effect of bandwidth on the 385 vulnerability is squared; for every increase in bandwidth, there is a 386 linear decrease in the number of sequence number guesses needed, as 387 well as a linear decrease in the time needed to send a set of 388 guesses. Notably, as inter-router link bandwidths approach 1 Mbps, 389 an 'exhaustive' attack becomes practical. Checking that the RST 390 sequence number is somewhere in the advertised receive window out of 391 the overall maximum receive window (2^32) is an insufficient 392 obfuscation. 394 Note that this table makes a number of assumptions: 396 1. the overall bandwidth-delay product is relatively fixed 398 2. traffic losses are negligible (insufficient to affect the 399 congestion window over the duration of most of the connection) 401 3. the advertised receive window is a large fraction of the overall 402 maximum receive window size, e.g., because the receive socket 403 buffers are set to match a large bandwidth-delay product 405 4. the attack bandwidth is similar to the end-to-end path bandwidth 407 Of these assumptions, the last two are more notable. The issue of 408 receive socket buffers was discussed in Sec. 2. Figure 1 summarized 409 the time to an successful attack based on large advertised receive 410 windows, but many current commercial routers have limits of 128KB for 411 large devices, 32KB for medium, and as little as 4KB for modest ones. 412 Figure 2 shows the time and bandwidths needed to accomplish an attack 413 on BGP sessions in the time shown for 100ms latencies; for even 414 short-range network latencies (10ms), these sessions can be still be 415 attacked over short timescales (minutes to hours). 417 BW BW*delay RSTs needed Time needed 418 ------------------------------------------------------------ 419 10 Mbps 0.128 MB 33,555 1 second 420 3 Mbps 0.032 MB 134,218 40 seconds 421 300 Kbps 0.004 MB 1,073,742 1 hour 423 Figure 2 Time needed to kill a connection with limited buffers 425 The issue of the attack bandwidth is considered reasonable as 426 follows: 428 1. RSTs are substantially easier to send than data; they can be 429 precomputed and they are smaller than data packets (40 bytes) 431 2. although susceptible connections use somewhat less ubiquitous 432 high-bandwidth paths, the attack may be distributed, at which 433 point only the ingress link of the attack is the primary 434 limitation 436 3. for the purposes of the above table, we assume that the ingress at 437 the attack has the same bandwidth as the path, as an approximation 439 The previous sections discussed the nature of the recent attacks on 440 BGP due to the vulnerability of TCP to RST spoofing attacks, due 441 largely to recent increases in the fraction of the TCP advertised 442 receive window space in use for a single, long-lived connection. 444 3. Proposed Solutions and Mitigations 446 TCP currently authenticates received RSTs using the address and port 447 pair numbers, and checks that the sequence number is inside the valid 448 receiver window. The previous section demonstrated how TCP has 449 become more vulnerable to RST spoofing attacks due to the increases 450 in the receive window size. There are a number of current and 451 proposed solutions to this vulnerability, all attempting to provide 452 evidence that a received RST is legitimate. 454 3.1. Transport Layer Solutions 456 The transport layer represents the last place that segments can be 457 authenticated before they affect connection management. TCP has a 458 variety of current and proposed mechanisms to increase the 459 authentication of segments, protecting against both off-path and on- 460 path third-party spoofing attacks. Other transport protocols, such 461 as SCTP and DCCP, also have limited antispoofing mechanisms. 463 3.1.1. TCP MD5 Authentication 465 An extension to TCP supporting MD5 authentication was developed in 466 1998 specifically to authenticate BGP connections (although it can be 467 used for any TCP connection) [20]. The extension relies on a pre- 468 shared secret key to authenticate the entire TCP segment, including 469 the data, TCP header, and TCP pseudo-header (certain fields of the IP 470 header). All segments are protected, including RSTs, to be accepted 471 only when their signature matches. This option, although widely 472 deployed in Internet routers, is considered undeployable for 473 widespread use because the need for pre-shared keys [3][30]. It 474 further is considered computationally expensive for either hosts or 475 routers due to the overhead of MD5 [43][44]. 477 There are also concerns about the use of MD5 due to recent collision- 478 based attacks [22]. Similar concerns exist for SHA-1, and the IETF 479 is currently evaluating how these attacks impact the recommendation 480 for using these hashes, both in TCP/MD5 and in the IPsec suite. For 481 the purposes of this discussion, the particular algorithm used in 482 either protocol suite is not the focus, and there is ongoing work to 483 allow TCP/MD5 to evolve to a more general TCP security option [6]. 485 3.1.2. TCP RST Window Attenuation 487 A recent proposal extends TCP to further constrain received RST to 488 match the expected next sequence number [36]. This restores TCP's 489 resistance to spurious RSTs, effectively limiting the receive window 490 for RSTs to a single number. As a result, an attacker would need to 491 send 2^32 different packets to brute-force guess the sequence number 492 (worst case, average would be half that); this makes TCP's 493 vulnerability to attack independent of the size of the receive window 494 (RCV.WND). The extension further modifies the RST receiver to react 495 to incorrectly-numbered RSTs, by sending a zero-length ACK. If the 496 RST source is legitimate, upon receipt of an ACK the closed source 497 would presumably emit a RST with the sequence number matching the 498 ACK, correctly resetting the intended recipient. This modification 499 changes TCP's control processing, adding to its complexity and thus 500 potentially affecting its correctness (in contrast to adding MD5 501 signatures, which is orthogonal to TCP control processing 502 altogether). For example, there may be complications between RSTs of 503 different connections between the same pair of endpoints because RSTs 504 flush the TIME-WAIT (as mentioned earlier). Further, this proposal 505 modifies TCP so that under some circumstances a RST causes a reply 506 (an ACK), in violation of generally accepted practice, if not gentle 507 recommendation - although this can be omitted, allowing timeouts to 508 suffice. The advantage to this proposal is that it can be deployed 509 incrementally and has benefit to the endpoint on which it is 510 deployed. The other advantage to this proposal is that the window 511 attenuation described here makes the vulnerability to spoofed RST 512 packets independent of the size of the receive window. 514 A variant of this proposal uses a different value to attenuate the 515 window of viable RSTs. It requires RSTs to carry the initial 516 sequence number rather than the next expected sequence number, i.e., 517 the value negotiated on connection establishment [42][48]. This 518 proposal has the advantage of using an explicitly negotiated value, 519 but at the cost of changing the behavior of an unmodified endpoint to 520 a currently valid RST. It would thus be more difficult, without 521 additional mechanism, to deploy incrementally. 523 Another variant of this proposal involves increasing TCP's window 524 space, rather than decreasing the valid range for RSTs, i.e., 525 increasing the sequence space from 32 bits to 64 bits. This has the 526 equivalent effect - the ratio of the valid sequence numbers for any 527 segment to the overall sequence number space is significantly 528 reduced. The use of the larger space, as with current schemes to 529 establish weak authentication using initial sequence numbers (ISNs), 530 is contingent on using suitably random values for the ISN. Such 531 randomness adds additional complexity to TCP both in specification 532 and implementation, and provides only very weak authentication. Such 533 a modification is not obviously backward compatible, and would be 534 thus difficult to deploy. 536 A converse variant of increasing TCP's window space is to decrease 537 the receive window (RCV.WND) explicitly, which would further reduce 538 the effectiveness of spoofed RSTs with random sequence numbers. This 539 alternative may reduce the throughput of the connection, if the 540 advertised receive window is smaller than the bandwidth-delay product 541 of the connection. 543 3.1.3. TCP Timestamp Authentication 545 Another way to authenticate TCP segments is via its timestamp option, 546 using the value as a sort of authentication [34]. This requires that 547 the receiver TCP discard segments whose timestamp is outside the 548 accepted window, which is derived from the timestamps of other 549 packets from the same connection. This technique uses an existing 550 TCP option, but also requires modified TCP control processing (with 551 the same caveats) and may be difficult to deploy incrementally 552 without further modifications. Additionally, the timestamp value may 553 be easier to guess because it can be derived predictably, either 554 assuming it represents actual time at the host, or by probing the 555 host using unrelated benign traffic. 557 3.1.4. Other TCP Cookies 559 All of the above techniques are variants of cookies, otherwise 560 meaningless data whose value is used to validate the packet. In the 561 case of MD5 checksums, the cookie is computed based on a shared 562 secret. Note that even a signature can be guessed, and presents a 1 563 in 2^(signature length) probability of attack. The primary 564 difference is that MD5 signatures are effectively one-time cookies, 565 not predictable based on on-path snooping, because they are dependent 566 on packet data and thus do not repeat. Window attenuation sequence 567 numbers can be guessed by snooping the sequence number of current 568 packets of an existing connection, and timestamps can be guessed even 569 less directly, either by separate benign connections or by assuming 570 reasonably correlation to local time. These variants of cookies are 571 similar in spirit to TCP SYN cookies, again patching a vulnerability 572 to off-path third-party spoofing attacks based on a (fairly weak, 573 excepting MD5) form of authentication. Another form of cookie is the 574 source port itself, which can be randomized but provides only 16 bits 575 of protection (65,000 combinations), which may be exhaustively 576 attacked. This can be combined with destination port randomization 577 as well, but that would require a separate coordination mechanism (so 578 both parties know which ports to use), which is equivalent to (and as 579 infeasible for large-scale deployments as) exchanging a shared secret 580 [39]. 582 3.1.5. Other TCP Considerations 584 The analysis of the potential for RST spoofing above assumes that the 585 advertised receive window is opened to the maximum extent suggested 586 by the bandwidth-delay product of the end-to-end path, and that the 587 window is opened to an appreciable fraction of the overall sequence 588 number space. As noted earlier, for most common cases, connections 589 are too brief or over bandwidths too low for such a large window to 590 be useful. Expanding TCP's sequence number space is a direct way to 591 further avoid such vulnerability, even for long connections over 592 emerging bandwidths. If either manual tuning or automatic tuning of 593 the advertised receive window (via receive buffer tuning) is not 594 provided, this is not an issue (although connection performance will 595 suffer) [38]. 597 It may be sufficient for the endpoint to limit the advertised receive 598 window by deliberately leaving it small. If the receive socket 599 buffer is limited, e.g., to the ubiquitous default of 64KB, the 600 advertised receive window will not be as vulnerable even for very 601 long connections over very high bandwidths. The vulnerability will 602 grow linearly with the increased network speed, but not as the 603 square. The consequence is lower sustained throughput, where only 604 one window's worth of data per round trip time (RTT) is exchanged. 605 This will keep the connection open longer; for long-lived connections 606 with continuous sourced data, this may continue to present an attack 607 opportunity, albeit a sparse and slow-moving target. For the most 608 recent case where BGP data is being exchanged between Internet 609 routers, the data is bursty and the aggregate traffic may be small 610 (i.e., unlikely to cover a substantial portion of the sequence space, 611 even if long-lived), so smaller advertised receive windows (via small 612 receiver buffers) may, in some cases, sufficiently address the 613 immediate problem. This assumes that the routing tables can be 614 exchanged quickly enough with bandwidth reduced due to the smaller 615 buffers, or perhaps that the advertised receive window is opened only 616 during a large burst exchange (e.g., via some other signal between 617 the two routers). 619 3.1.6. Other Transport Protocol Solutions 621 Segment authentication has been addressed at the transport layer in 622 other protocols. Both SCTP and DCCP include cookies for connection 623 establishment and use them to authenticate a variety of other control 624 messages [28][41]. The inclusion of such mechanism at the transport 625 protocol, although emerging as standard practice, complicates the 626 design and implementation of new protocols [32]. As new attacks are 627 discovered (SYN floods, RSTs, etc.), each protocol must be modified 628 individually to compensate. A network solution may be more 629 appropriate and efficient. 631 It should be noted that RST attacks which rely on brute-force are 632 relatively easy for intrusion detection software to detect at the TCP 633 layer. Any connection that receives a large number of invalid - 634 outside-window - RSTs might have subsequent RSTs blocked, to defeat 635 such attacks. This would have the side-effect of blocking legitimate 636 RSTs to that connection, which might then interfere with cleaning up 637 the transport state between the endpoint peers. This side-effect, 638 coupled with the increased monitoring load, might render such 639 solutions undesirable in the general case, but they might usefully be 640 applied to special cases, e.g., for BGP for routers. 642 3.2. Network Layer (IP) Solutions 644 There are two primary variants of network layer solutions to 645 spoofing: address filtering and IPsec. Address filtering is an 646 indirect system which relies on other parties to filter packets sent 647 upstream of an attack, but does not necessarily require participation 648 of the packet source. IPsec requires cooperation between the 649 endpoints wanting to avoid attack on their connection, which 650 currently involves pre-existing shared knowledge of either a shared 651 key or shared certificate authority. 653 3.2.1. Address filtering 655 Address filtering is often proposed as an alternative to protocol 656 mechanisms to defeat IP source address spoofing [2][13]. Address 657 filtering restricts traffic from downstream sources across transit 658 networks based on the IP source address. A kind of filtering already 659 occurs at the endpoints of a connection, because attack messages must 660 match the socket pair to succeed; again, note that such attacks 661 require knowing the entire socket pair, and are unlikely except in 662 particular cases. This section discusses filtering based on address 663 only, typically done at the borders of an AS. 665 It can also restrict core-to-edge paths to reject traffic that should 666 have originated further toward the edge. It cannot restrict traffic 667 from edges lacking filtering through the core to a particular edge. 668 As a result, each border router must perform the appropriate 669 filtering for overall protection to result; failure of any border 670 router to filter defeats the protection of all participants inside 671 the border, and potentially those outside as well. Address filtering 672 at the border can protect those inside the border from some kinds of 673 spoofing, i.e., connections among those inside a border, because only 674 interior addresses should originate inside the border. It cannot, 675 however, protect connections including connections outside the border 676 except to restrict where the traffic enters from, e.g., if it 677 expected from one AS and not another. 679 As a result, address filtering is not a local solution that can be 680 deployed to protect communicating pairs, but rather relies on a 681 distributed infrastructure of trusted gateways filtering forged 682 traffic where it enters the network. It is not feasible for local, 683 incremental deployment, but may be applicable to connections among 684 those inside the protected border in some scenarios. Applying 685 filtering can also be useful to reduce the network load of spoofed 686 traffic [31]. 688 A more recent variant of address filtering checks the IP TTL field, 689 relying on the TTL set by the other end of the connection [15]. This 690 technique has been used to provide filtering for BGP. It assumes the 691 connection source TTL is set to 255; packets at the receiver are 692 checked for TTL=255, and others are dropped. This restricts traffic 693 to one hop upstream of the receiver (i.e., a BGP router), but those 694 hops could include other user programs at those nodes (e.g., the BGP 695 router's peer) or any traffic those nodes accept via tunnels - 696 because tunnels need not decrement TTLs, notably for "bump in the 697 wire" (BITW) or BITW-equivalent scenarios [33] (see also Sec. 5.1 of 698 [15] and [16]). TTL filtering works only where all traffic from the 699 other end of the tunnel is trusted, i.e., where it does not originate 700 or transit spoofed traffic. The use of TTL rather than link or 701 network security also assumes an untampered point-to-point link, 702 where no other traffic can be spoofed onto a link. 704 This method of filtering works best where traffic originates one hop 705 away, so that the address filtering is based on the trust of only 706 directly-connected (tunneled or otherwise) nodes. Like conventional 707 address filtering, this reduces spoofing traffic in general, but is 708 not considered a reliable security mechanism because it relies on 709 distributed filtering (e.g., the fact that upstream nodes do not 710 terminate tunnels arbitrarily). 712 3.2.2. IPsec 714 TCP is susceptible to RSTs, but also to other off-path and on-path 715 spoofing attacks, including SYN attacks. Other transport protocols, 716 such as UDP and RTP are equally susceptible. Although emerging 717 transport protocols attempt to defeat such attacks at the transport 718 layer, such attacks take advantage of network layer identity 719 spoofing. The packet is coming from an endpoint who is spoofing 720 another endpoint, either upstream or somewhere else in the Internet. 721 IPsec was designed specifically to establish and enforce 722 authentication of a packet's source and contents, to most directly 723 and explicitly address this security vulnerability. 725 The larger problem with IPsec is that of key distribution and use. 726 IPsec is often cumbersome, and has only recently been supported in 727 many end-system operating systems. More importantly, it relies on 728 preshared keys, signed X.509 certificates, or a third-party (e.g., 729 Kerberos) public key infrastructure to establish and exchange keying 730 information (e.g., via IKE). Each of these issues presents 731 challenges when using IPsec to secure traffic to a well-known server, 732 whose clients may not support IPsec or may not have registered with a 733 previously-known certificate authority (CA). 735 These keying challenges are being addressed in the IETF in ways that 736 will enable servers secure associations with other parties without 737 advance coordination [45][46]. This can be especially useful for 738 publicly-available servers, or for protecting connections to servers 739 that - for whatever reason - have not, or will not deploy 740 conventional IPsec certificates (i.e., core Internet BGP routers). 742 4. ICMP 744 Just as spoofed TCP packets can terminate a connection, so too can 745 spoofed ICMP packets. ICMP can be used to launch a variety of 746 attacks on TCP including connection resets, path-MTU attacks, and can 747 also be used to attack the host with non-TCP 'ping of death' and 748 'smurf attacks', etc. [40]. ICMP thus represents a substantial 749 threat to TCP, but this is not the focus of this document, although a 750 number of protections are discussed below because some are comparable 751 to TCP anti-spoofing techniques. Note also that ICMP attacks on TCP 752 assume that the socket pair is known by the attacker, which is 753 unlikely except for a subset of services between pairs of widely- 754 known endpoints. 756 TCP headers can be included inside certain ICMP messages [7]. There 757 have been recent suggestions to validate the sequence number of TCP 758 headers when they occur inside ICMP messages [18]. This sequence 759 checking is similar to checks that would occur for conventional data 760 packets in TCP, but is being proposed in the spirit of the RST window 761 attenuation described in Section 3.1.2. 763 Some such checks may be reasonable, especially where they parallel 764 the validations already performed by TCP processing, notably where 765 they emulate the semantics of such processing. For example, the TCP 766 checksum should be validated (if the entire TCP segment is contained 767 in the ICMP message) before any fields of the TCP header are 768 examined, to avoid reacting to corrupted packets. Similarly, if the 769 TCP MD5 option is present, its signature should probably be validated 770 before considering the contents of the message. Such validation can 771 ensure that the packet was not corrupted prior to the ICMP generation 772 (checksum), that the packet was one sent by the source (IPsec or 773 TCP/MD5 authenticated), or that the packet was not in the network for 774 an excess of 2*MSL (valid sequence number). 776 ICMP presents a particular challenge because some messages can reset 777 a connection more easily - with less validation - than even some 778 spoofed TCP segments. One other proposed alternative is to change 779 TCP's reaction to ICMPs after a connection is established; that may 780 leave TCP susceptible during connection establishment and modifies 781 TCP's reaction to certain valid network events [19]. This considers 782 the context-sensitivity of ICMP messages, as does IPsec in some 783 tunneled configurations, but the recommendations are ambiguous 784 regarding such filtering [27]. 786 Ultimately, requiring TCP ICMP messages to be 'in window' may be 787 insufficient protection, as this document shows for spoofed data. 788 ICMP packets can be authenticated when originating at known, trusted 789 endpoints, such as endpoints of connections or routers in known 790 domains with pre-existing IPsec associations. Unfortunately, they 791 also can originate at other places in the network. In addition, some 792 networks filter all ICMP packets because validation may not be 793 possible, especially because they can be injected from anywhere in a 794 network, and so cannot be easily and locally address filtered [27]. 795 As a result, they are not addressed separately in the issues or 796 security considerations of this document further. 798 5. Issues 800 There are a number of existing and proposed solutions addressing the 801 vulnerability of transport protocols in general (and TCP in specific) 802 to off-path third-party spoofing attacks. As shown, these operate at 803 the transport or network layer. Transport solutions require separate 804 modification of each transport protocol, addressing network identity 805 spoofing separately in the context of each transport association. 806 Network solutions require distributed coordination (filtering) or can 807 be computationally intensive and require pervasive registration of 808 certificate authorities with every possible endpoint 809 (authentication). This section explains these observations further. 811 5.1. Transport Layer (e.g., TCP) 813 Transport solutions rely on shared cookies to authenticate segments, 814 including data, transport header, and even pseudo-header (e.g., fixed 815 portions of the outer IP header in TCP). Because the Internet relies 816 on stateless network protocols, it makes sense to rely on state 817 establishment and maintenance available in some transport layers not 818 only for the connection but for authentication state. Three-way 819 handshakes and heartbeats can be used to negotiate authentication 820 state in conjunction with connection parameters, which can be stored 821 with connection state easily. 823 As noted earlier, transport layer solutions require separate 824 modification of all transport protocols to include authentication. 825 Not all transport protocols support negotiated endpoint state (e.g., 826 UDP), and legacy protocols have been notoriously difficult to safely 827 augment. Not all authentication solutions are created equal either, 828 and relying on a variety of transport solutions exposes end-systems 829 to increased potential for incorrectly specified or implemented 830 solutions. Transport authentication has often been developed piece- 831 wise, in response to specific attacks, e.g., SYN cookies and RST 832 window attenuation [4][36]. 834 Transport layer solutions are not only per-protocol, but often per- 835 connection. This has both advantages and drawbacks. One advantage 836 to transport layer solutions is that they can protect the transport 837 protocol when lower layers have failed, e.g., due to bugs in 838 implementation. TCP already includes a variety of packet validation 839 mechanisms to protect in these cases, e.g., checking that RSTs are 840 in-window. More strict checks can increase the protections provided, 841 e.g., to protect against misaddressed RSTs that end up in-window (via 842 TCPsecure) or to protect against connection interruption due to RSTs, 843 SYNs, or data injection from misaddressed packets (TCP/MD5) [36]. 845 Another advantage is that transport layer protections can be more 846 specifically limited to a particular connection. Because each 847 connection negotiates its state separately, that state can be more 848 specifically tied to that connection. This is both an advantage and 849 a drawback. It can make it easier to tie security to an individual 850 connection, although in practice a shared secret or certificate will 851 generally be shared across multiple connections. 853 As a drawback, each transport connection needs to negotiate and 854 maintain authentication state separately. Some overhead is not 855 amortized over multiple connections, e.g., overheads in packet 856 exchanges, whereas other overheads are not amortized over different 857 transport protocols, e.g., design and implementation complexity - 858 both as would be the case in a network layer solution. Because the 859 authentication happens later in packet processing than is required, 860 additional endpoint resources may be needlessly consumed, e.g., in 861 demultiplexing received packets, indexing connection identifiers, and 862 continuing to buffer spoofed packets, etc., only to be dropped later 863 at the transport layer. 865 5.2. Network Layer (IP) 867 A network layer solution avoids the hazards of multiple transport 868 variants, using a single shared endpoint authentication mechanism 869 early in receiver packet processing to discard unauthenticated 870 packets at the network layer instead. This defeats spoofing entirely 871 because spoofing involves masquerading as another endpoint, and 872 network layer security validates the endpoint as the source of the 873 packets it emits. Such a network level solution protects all 874 transport protocols as a result, including both legacy and emerging 875 protocols, and reduces the complexity of these protocols as well. A 876 shared solution also reduces protocol overhead, and decouples the 877 management (and refreshing) of authentication state from that of 878 individual transport connections. Finally, a network layer solution 879 protects not only the transport layer but the network layer as well, 880 e.g., from IGMP, and some kinds of ICMP (Sec. 4), spoofing attacks. 882 The IETF Proposed Standard protocol for network layer authentication 883 is IPsec [27]. IPsec specifies the overall architecture, including 884 header authentication (AH) [25] and encapsulation (ESP) modes [26]. 885 AH authenticates both the IP header and IP data, whereas ESP 886 authenticates only the IP data (e.g., transport header and payload). 887 AH is being phased out since ESP is more efficient and the Security 888 Parameters Index (SPI) includes sufficient information to verify the 889 IP header anyway [27]. These two modes describe the security applied 890 to individual packets within the IPsec system; key exchange and 891 management is performed either out-of-band (via pre-shared keys) or 892 by an automated key exchange protocol IKE [24]. 894 IPsec already provides authentication of an IP header and its data 895 contents sufficient to defeat both on-path and off-path third-party 896 spoofing attacks. IKE can configure authentication between two 897 endpoints on a per-endpoint, per-protocol, or per-connection basis, 898 as desired. IKE also can perform automatic periodic re-keying, 899 further defeating crypto-analysis based on snooping (clandestine data 900 collection). The use of IPsec is already commonly strongly 901 recommended for protected infrastructure. 903 Existing IPsec is not appropriate for many deployments. It is 904 computationally intensive both in key management and individual 905 packet authentication [43]. This computational overhead can be 906 prohibitive, and so often requires additional hardware, especially in 907 commercial routers. As importantly, IKE is not anonymous; keys can 908 be exchanged between parties only if they trust each others' X.509 909 certificates, trust some other third-party to help with key 910 generation (e.g., Kerberos), or pre-share a key. These certificates 911 provide identification (the other party knows who you are) only where 912 the certificates themselves are signed by certificate authorities 913 (CAs) that both parties already trust. To a large extent, the CAs 914 themselves are the pre-shared keys which help IKE establish security 915 association keys, which are then used in the authentication 916 algorithms. 918 Alternative mechanisms are under development to address this 919 limitation, to allow publicly-accessible servers to secure 920 connections to clients not known in advance, or to allow unilateral 921 relaxation of identity validation so that the remaining protections 922 of IPsec can be made available [45][46]. In particular, these 923 mechanisms can prevent a client (but without knowing who that client 924 is) from being affected by spoofing from other clients, even when the 925 attackers are on the same communications path. 927 IPsec, although widely available both in commercial routers and 928 commodity end-systems, is not often used except between parties that 929 already have a preexisting relationship (employee/employer, between 930 two ISPs, etc.). Servers to anonymous clients (e.g., customer/ 931 business) or more open services (e.g., BGP, where routers may have 932 large numbers of peers) are unmanageable, due to the breadth and flux 933 of CAs. New endpoints cannot establish IPsec associations with such 934 servers unless their own certificate is signed by a CA already 935 trusted by the server. Different servers - even within the same 936 overall system (e.g., BGP) - often cannot or will not trust 937 overlapping subsets of CAs in general. 939 5.3. Application Layer 941 There are a number of application layer authentication mechanisms, 942 often implicit within end-to-end encryption. Application-layer 943 security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) 944 provides the ultimate protection of application data from all 945 intermediaries, including network routers as well as exposure at 946 other layers in the end-systems. This is the only way to ultimately 947 protect the application data. 949 Application authentication cannot protect either the network or 950 transport protocols from spoofing attacks, however. Spoofed packets 951 interfere with network processing or reset transport connections 952 before the application checks the data. Authentication needs to 953 winnow these packets and drop them before they interfere at these 954 lower layers. 956 An alternate application layer solution would involve resilience to 957 reset connections. If the application can recover from such 958 connection interruptions, then such attacks have less impact. 959 Unfortunately, attackers still affect the application, e.g., in the 960 cost of restarting connections, delays until connections are 961 restarted, or increased connection establishment messages on the 962 network. Some applications - notably BGP - even interpret TCP 963 connection reliability as an indicator of route path stability, which 964 is why attacks on BGP have such substantial consequences. 966 5.4. Link Layer 968 Link layer security operates separately on each hop of an Internet. 969 Such security can be critical in protecting link resources, such as 970 bandwidth and link management protocols. Protection at this layer 971 cannot suffice for network or transport layers, because it cannot 972 authenticate the endpoint source of a packet. Link authentication 973 ensures only the source of the current link hop where it is examined. 975 5.5. Issues Discussion 977 The issues raised in this section suggest that there are challenges 978 with all solutions to transport protection from spoofing attacks. 979 This raises the potential need for alternate security levels. While 980 it is already widely recognized that security needs to occur 981 simultaneously at many protocol layers, there also may be utility in 982 supporting a variety of strengths at a single layer. For example, 983 IPsec already supports a variety of algorithms (MD5, SHA1, etc., for 984 authentication), but always assumes that: 986 1. the entire body of the packet is secured 988 2. security associations are established only where identity is 989 authenticated by a know certificate authority or other pre-shared 990 key 992 3. both on-path and off-path third-party spoofing attacks must be 993 defeated 995 These assumptions are prohibitive, especially in many cases of 996 spoofing attacks. For spoofing, the primary issue is whether packets 997 are coming from the same party the server can reach. Only the IP 998 header is fundamentally in question, so securing the entire packet 999 (1) is computational overkill. It is sufficient to authenticate the 1000 other party as "a party you have exchanged packets with", rather than 1001 establishing their trusted identity ("Bill" vs. "Bob") as in (2). 1002 Finally, many cookie systems use clear-text (unencrypted), fixed 1003 cookie values, providing reasonable (1 in 2^{cookie-size}) protection 1004 against off-path third-party spoof attacks, but not addressing on- 1005 path attacks at all. Such potential solutions are discussed in the 1006 BTNS documents [5][45][46]. Note also that NULL Encryption in IPsec 1007 applies a variant of this cookie, where the SPI is the cookie, and no 1008 further encryption is applied [17]. 1010 6. Security Considerations 1012 This entire document focuses on increasing the security of transport 1013 protocols and their resistance to spoofing attacks. Security is 1014 addressed throughout. 1016 This document describes a number of techniques for defeating spoofing 1017 attacks. Those relying on clear-text cookies, either explicit or 1018 implicit (e.g., window sequence attenuation) do not protect from on- 1019 path spoofing attacks, since valid values can be learned from prior 1020 traffic. Those relying on true authentication algorithms are 1021 stronger, protecting even from on-path attacks, because the 1022 authentication hash in a single packet approaches the behavior of 1023 "one time" cookies. 1025 The security of various levels of the protocol stack is addressed. 1026 Spoofing attacks are fundamentally identity masquerading, so we 1027 believe the most appropriate solutions defeat these at the network 1028 layer, where end-to-end identity lies. Some transport protocols 1029 subsume endpoint identity information from the network layer (e.g., 1030 TCP pseudo-headers), whereas others establish per-connection identity 1031 based on exchanged nonces (e.g., SCTP). It is reasonable, if not 1032 recommended, to address security at all layers of the protocol stack. 1034 Note that NATs and other middleboxes complicate the design and 1035 deployment of techniques to defeat spoofing attacks. Devices such as 1036 these, that modify IP and/or TCP headers in-transit, generate traffic 1037 equivalent to a spoofing attack, and thus should be inhibited by 1038 antispoofing mechanisms. Details of these middlebox-related problems 1039 are out of scope for this document, but issues thereof are addressed 1040 in RFCs and emerging Internet Drafts that discuss the interactions 1041 between such devices and the Internet architecture, e.g., [21]. 1042 Fortunately, many of the most critical TCP-based connections, in 1043 particular supporting routing protocols like BGP, do not traverse 1044 such middleboxes, and are not affected by this limitation. 1046 7. IANA Considerations 1048 There are no IANA considerations in this document. 1050 This section should be removed by the RFC-Editor upon publication as 1051 an RFC. 1053 8. Conclusions 1055 This document describes the details of the recent BGP spoofing 1056 attacks involving spurious RSTs which could be used to shutdown TCP 1057 connections. It summarizes and discusses a variety of current and 1058 proposed solutions at various protocol layers. 1060 9. Acknowledgments 1062 This document was inspired by discussions in the TCPM WG 1063 about the 1064 recent spoofed RST attacks on BGP routers, including R. Stewart's 1065 draft (whose author list has since evolved) [36][42]. The analysis 1066 of the attack issues, alternate solutions, and the anonymous security 1067 proposed solutions were the result of discussions on that list as 1068 well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. R. 1070 Atkinson suggested the UDP variant of TCP/MD5, P. Goyette suggested 1071 using the ISN to seed TCP/MD5, and L. Wood suggested using the ISN to 1072 validate RSTs. Other improvements are due to the input of various 1073 members of the IETF's TCPM WG, notably detailed feedback from F. 1074 Gont, P. Savola, and A. Hoenes. 1076 This document was prepared using 2-Word-v2.0.template.dot. 1078 10. References 1080 10.1. Normative References 1082 None. 1084 10.2. Informative References 1086 [1] Allman, M., V. Paxson, and W. Stephens, "TCP Congestion 1087 Control", RFC 2581 (Proposed Standard), Apr. 1999. 1089 [2] Baker, F., and P. Savola, "Ingress Filtering for Multihomed 1090 Networks", RFC 3704 / BCP 84, Mar. 2004. 1092 [3] Bellovin, S., and A. Zinin, "Standards Maturity Variance 1093 Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 1094 Specification", RFC 4278 (Informational), Jan. 2006. 1096 [4] Bernstein, D., "SYN cookies", http://cr.yp.to/syncookies.html, 1097 1997. 1099 [5] Better Than Nothing Security [BTNS] WG web pages, 1100 http://www.postel.org/anonsec 1102 [6] Bonica, R., B. Weis, S. Viswanathan, A. Lange, and O. Wheeler, 1103 "Authentication for TCP-based Routing and Management 1104 Protocols", draft-bonica-tcp-auth-06 (work in progress), Feb. 1105 2007. 1107 [7] Braden, R., "Requirements for Internet Hosts -- Communication 1108 Layers", RFC 1122 / STD 3, Oct. 1989. 1110 [8] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337 1111 (Informational), May 1992. 1113 [9] CERT alert: "Technical Cyber Security Alert TA04-111A: 1114 Vulnerabilities in TCP", 1115 http://www.us-cert.gov/cas/techalerts/TA04-111A.html, April 20 1116 2004. 1118 [10] Convery, S., and M. Franz, "BGP Vulnerability Testing: 1119 Separating Fact from FUD", 2003, 1120 http://www.nanog.org/mtg-0306/pdf/franz.pdf 1122 [11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", 1123 draft-ietf-tcpm-syn-flood-01.txt (work in progress), Dec. 2006. 1125 [12] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP 1126 and Its Effect on Busy Servers", Proc. Infocom 1999, pp. 1573- 1127 1583, Mar. 1999. 1129 [13] Ferguson, P., and D. Senie, "Network Ingress Filtering: 1130 Defeating Denial of Service Attacks which employ IP Address 1131 Spoofing", RFC 2827 / BCP 38, May 2000. 1133 [14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 1134 60, RFC 3360 / BCP 60, Aug. 2002. 1136 [15] Gill, V., J. Heasley, and D. Meyer, "The Generalized TTL 1137 Security Mechanism (GTSM)", RFC 3682 (Experimental), Feb. 2004. 1139 [16] Gill, V., J. Heasley, D. Meyer, P. Savola, Ed., and C. 1140 Pignataro, "The Generalized TTL Security Mechanism (GTSM)" 1141 draft-ietf-rtgwg-rfc3682bis-09.txt (work in progress), Jan. 1142 2007. 1144 [17] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and Its 1145 Use With IPsec", RFC 2410 (Proposed Standard), Nov. 1998. 1147 [18] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm-icmp- 1148 attacks-01.txt (work in progress), Oct. 2006. 1150 [19] Gont, F., "TCP's Reaction to Soft Errors", draft-ietf-tcpm-tcp- 1151 soft-errors-03.txt (work in progress), Jan. 2007. 1153 [20] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1154 Signature Option", RFC 2385 (Proposed Standard), Aug. 1998. 1156 [21] Holdrege, M., and P. Srisuresh, "Protocol Complications with 1157 the IP Network Address Translator", RFC 3027 (Informational), 1158 Jan. 2001. 1160 [22] Housley, R., Post to IETF Discussion mailing list regarding his 1161 IETF 64 Security Area presentation, 1162 ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24, 1163 2005, http://www1.ietf.org/mail- 1164 archive/ietf/Current/maillist.html 1166 [23] Jacobson, V., B. Braden, and D. Borman, "TCP Extensions for 1167 High Performance", RFC 1323 (Proposed Standard), May 1992. 1169 [24] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306 1170 (Proposed Standard), Dec. 2005. 1172 [25] Kent, S., "IP Authentication Header", RFC 4302 (Proposed 1173 Standard), Dec. 2005. 1175 [26] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 4303 1176 (Proposed Standard), Dec. 2005. 1178 [27] Kent, S., and K. Seo, "Security Architecture for the Internet 1179 Protocol", RFC 4301 (Proposed Standard), Dec. 2005. 1181 [28] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1182 Control Protocol (DCCP)", RFC 4340 (Proposed Standard), Dec. 1183 2005. 1185 [29] Larsen, M., and F. Gont, "Port Randomization", draft-larsen- 1186 tsvwg-port-randomization-01.txt (work in progress), Feb. 2007. 1188 [30] Leech, M., "Key Management Considerations for the TCP MD5 1189 Signature Option", RFC 3562 (Informational), July 2003. 1191 [31] Moore, D., G. Voelker, and S. Savage, "Inferring Internet 1192 Denial-of-Service Activity", Proc. Usenix Security Symposium, 1193 Aug. 2001. 1195 [32] O'Malley, S., and L. Peterson, "TCP Extensions Considered 1196 Harmful", RFC 1263 (Informational), October 1991. 1198 [33] Perkins, C., "IP Encapsulation within IP", RFC 2003 (Proposed 1199 Standard), Oct. 1996. 1201 [34] Poon, K., "Use of TCP timestamp option to defend against blind 1202 spoofing attack", draft-poon-tcp-tstamp-mod-01.txt (expired 1203 work in progress), Oct. 2004. 1205 [35] Postel, J., "Transmission Control Protocol", RFC 793 / STD 7, 1206 Sep. 1981. 1208 [36] Ramaiah, A., R. Stewart, and M. Dalal, "Improving TCP's 1209 Robustness to Blind In-Window Attacks", draft-ietf-tcpm- 1210 tcpsecure-06.txt (work in progress), Nov. 2006. 1212 [37] Rekhter, Y., T. Li, and S. Hares (eds.), "A Border Gateway 1213 Protocol 4 (BGP-4)", RFC 4271 (Draft Standard), Jan. 2006. 1215 [38] Semke, J., J. Mahdavi, and M. Mathis, "Automatic TCP Buffer 1216 Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume 1217 28, number 4, Oct. 1998. 1219 [39] Shepard, T., "Reassign Port Number option for TCP", draft- 1220 shepard-tcp-reassign-port-number-00.txt (expired work in 1221 progress), Jul. 2004. 1223 [40] Shirey, R., "Internet Security Glossary, Version 2", draft- 1224 shirey-secgloss-v2-08.txt (work in progress), Nov. 2006. 1226 [41] Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, 1227 T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, 1228 "Stream Control Transmission Protocol", RFC 2960 (Proposed 1229 Standard), Oct. 2000. 1231 [42] TCPM: IETF TCPM Working Group and mailing list, 1232 http://www.ietf.org/html.charters/tcpm-charter.html. 1234 [43] Touch, J., "Report on MD5 Performance", RFC 1810 1235 (Informational), Jun. 1995. 1237 [44] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995, 1238 pp. 77-86, Mar. 1999. 1240 [45] Touch, J., "ANONsec: Anonymous Security to Defend Against 1241 Spoofing Attacks", draft-touch-anonsec-00.txt (expired work in 1242 progress), May 2004. 1244 [46] Touch, J., D. Black, and Y. Wang, "Problem and Applicability 1245 Statement for Better Than Nothing Security (BTNS)", 1246 draft-ietf-btns-prob-and-applic-05.txt (work in progress), Feb. 1247 2007. 1249 [47] Watson, P., "Slipping in the Window: TCP Reset attacks", 1250 Presentation at 2004 CanSecWest. 1251 http://www.cansecwest.com/archives.html 1253 [48] Wood, L., Post to TCPM mailing list regarding use of ISN in 1254 RSTs, ID=Pine.GSO.4.50.0404232249570.5889- 1255 100000@argos.ee.surrey.ac.uk, Apr. 23, 2004. 1256 http://www1.ietf.org/mail- 1257 archive/web/tcpm/current/msg00213.html 1259 Author's Addresses 1261 Joe Touch 1262 USC/ISI 1263 4676 Admiralty Way 1264 Marina del Rey, CA 90292-6695 1265 U.S.A. 1267 Phone: +1 (310) 448-9151 1268 Fax: +1 (310) 448-9300 1269 Email: touch@isi.edu 1270 URI: http://www.isi.edu/touch 1272 Intellectual Property Statement 1274 The IETF takes no position regarding the validity or scope of any 1275 Intellectual Property Rights or other rights that might be claimed to 1276 pertain to the implementation or use of the technology described in 1277 this document or the extent to which any license under such rights 1278 might or might not be available; nor does it represent that it has 1279 made any independent effort to identify any such rights. Information 1280 on the procedures with respect to rights in RFC documents can be 1281 found in BCP 78 and BCP 79. 1283 Copies of IPR disclosures made to the IETF Secretariat and any 1284 assurances of licenses to be made available, or the result of an 1285 attempt made to obtain a general license or permission for the use of 1286 such proprietary rights by implementers or users of this 1287 specification can be obtained from the IETF on-line IPR repository at 1288 http://www.ietf.org/ipr. 1290 The IETF invites any interested party to bring to its attention any 1291 copyrights, patents or patent applications, or other proprietary 1292 rights that may cover technology that may be required to implement 1293 this standard. Please address the information to the IETF at 1294 ietf-ipr@ietf.org. 1296 Disclaimer of Validity 1298 This document and the information contained herein are provided on an 1299 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1300 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1301 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1302 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1303 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1306 Copyright Statement 1308 Copyright (C) The IETF Trust (2007). 1310 This document is subject to the rights, licenses and restrictions 1311 contained in BCP 78, and except as set forth therein, the authors 1312 retain all their rights. 1314 Acknowledgment 1316 Funding for the RFC Editor function is currently provided by the 1317 Internet Society.