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