diff options
Diffstat (limited to 'doc/rfc/rfc4953.txt')
| -rw-r--r-- | doc/rfc/rfc4953.txt | 1571 |
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc4953.txt b/doc/rfc/rfc4953.txt new file mode 100644 index 0000000..4a295c9 --- /dev/null +++ b/doc/rfc/rfc4953.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group J. Touch +Request for Comments: 4953 USC/ISI +Category: Informational July 2007 + + + Defending TCP Against Spoofing Attacks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + Recent analysis of potential attacks on core Internet infrastructure + indicates an increased vulnerability of TCP connections to spurious + resets (RSTs), sent with forged IP source addresses (spoofing). TCP + has always been susceptible to such RST spoofing attacks, which were + indirectly protected by checking that the RST sequence number was + inside the current receive window, as well as via the obfuscation of + TCP endpoint and port numbers. For pairs of well-known endpoints + often over predictable port pairs, such as BGP or between web servers + and well-known large-scale caches, increases in the path bandwidth- + delay product of a connection have sufficiently increased the receive + window space that off-path third parties can brute-force generate a + viable RST sequence number. The susceptibility to attack increases + with the square of the bandwidth, and thus presents a significant + vulnerability for recent high-speed networks. This document + addresses this vulnerability, discussing proposed solutions at the + transport level and their inherent challenges, as well as existing + network level solutions and the feasibility of their deployment. + This document focuses on vulnerabilities due to spoofed TCP segments, + and includes a discussion of related ICMP spoofing attacks on TCP + connections. + + + + + + + + + + + + +Touch Informational [Page 1] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Background ......................................................4 + 2.1. Review of TCP Windows ......................................5 + 2.2. Recent BGP Attacks Using TCP RSTs ..........................6 + 2.3. TCP RST Vulnerability ......................................6 + 2.4. What Changed - the Ever-Opening Advertised Receive Window ..7 + 3. Proposed Solutions and Mitigations .............................10 + 3.1. Transport Layer Solutions .................................10 + 3.1.1. TCP MD5 Authentication .............................11 + 3.1.2. TCP RST Window Attenuation .........................11 + 3.1.3. TCP Timestamp Authentication .......................12 + 3.1.4. Other TCP Cookies ..................................13 + 3.1.5. Other TCP Considerations ...........................13 + 3.1.6. Other Transport Protocol Solutions .................14 + 3.2. Network Layer (IP) Solutions ..............................14 + 3.2.1. Address Filtering ..................................15 + 3.2.2. IPsec ..............................................16 + 4. ICMP ...........................................................17 + 5. Issues .........................................................18 + 5.1. Transport Layer (e.g., TCP) ...............................18 + 5.2. Network Layer (IP) ........................................19 + 5.3. Application Layer .........................................21 + 5.4. Link Layer ................................................21 + 5.5. Issues Discussion .........................................21 + 6. Security Considerations ........................................22 + 7. Conclusions ....................................................23 + 8. Acknowledgments ................................................23 + 9. Informative References .........................................24 + + + + + + + + + + + + + + + + + + + + + +Touch Informational [Page 2] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +1. Introduction + + Analysis of the Internet infrastructure has recently demonstrated a + new version of a vulnerability in BGP connections between core + routers using an attack based on RST spoofing from off-path attackers + [9][10][48]. The attack itself is not new, having been documented + nearly six years earlier [20]. Such connections, typically using + TCP, can be susceptible to off-path third-party reset (RST) segments + with forged source addresses (spoofed), which terminate the TCP + connection. BGP routers react to a terminated TCP connection in + various ways, which can amplify the impact of an attack, ranging from + restarting the connection to deciding that the other router is + unreachable and thus flushing the BGP routes [37]. This sort of + attack affects other protocols besides BGP, involving any long-lived + connection between well-known endpoints. The impact on the Internet + infrastructure can be substantial (especially for the BGP case), and + warrants immediate attention. + + TCP, like many other protocols, can be susceptible to these off-path + third-party spoofing attacks. Such attacks rely on the increase of + commodity platforms supporting public access to previously privileged + resources, such as system-level (i.e., root) access. Given such + access, it is trivial for anyone to generate a packet with any header + desired. + + This, coupled with the lack of sufficient address filtering to drop + such spoofed traffic, can increase the potential for off-path third- + party spoofing attacks [9][10][48]. Proposed solutions include the + deployment of existing Internet network and transport security as + well as modifications to transport protocols that reduce its + vulnerability to generated attacks [13][15][20][36][46]. + + One way to defeat spoofing is to validate the segments of a + connection, either at the transport level or the network level. TCP + with MD5 extensions provides this authentication at the transport + level, and IPsec provides authentication at the network level + [20][24][27]. In both cases, their deployment overhead may be + prohibitive, e.g., it may not be feasible for public services, such + as web servers, to be configured with the appropriate certificate + authorities of large numbers of peers (for IPsec using the Internet + Key Exchange Protocol (IKE)), or shared secrets (for IPsec in + shared-secret mode, or TCP/MD5), because many clients may need to be + configured rapidly without external assistance. Services located on + public web servers connecting to large-scale caches or BGP with + larger numbers of peers can fall into this category. + + + + + + +Touch Informational [Page 3] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + The remainder of this document outlines the recent attack scenario in + detail and describes and compares a variety of solutions, including + existing solutions based on TCP/MD5 and IPsec, as well as recently + proposed solutions, including modifications to TCP's RST processing + [36], modifications to TCP's timestamp processing [34], and + modifications to IPsec and TCP/MD5 keying [45]. This document + focuses on spoofing of TCP segments, although a discussion of related + spoofing of ICMP packets based on spoofed TCP contents is also + discussed. + + Note that the description of these attacks is not new; attacks using + RSTs on BGP have been known since 1998, and were the reason for the + development of TCP/MD5 [20]. The recent attack scenario was first + documented by Convery at a NANOG (North American Network Operators' + Group) meeting in 2003, but that analysis assumed the entire sequence + space (2^32 packets) needed to be covered for an attack to succeed + [10]. Watson's more detailed analysis discovered that a single + packet anywhere in the current window could succeed at an attack + [48]. This document adds the observation that susceptibility to + attack is directly proportional to the square of bandwidth, due to + the coupling between the linear increase in receive window size and + linear increase in rate of a potential attack, as well as comparing + the variety of more recent proposals, including modifications to TCP, + use of IPsec, and use of TCP/MD5 to resist such attacks. + +2. Background + + The recent analysis of potential attacks on BGP has again raised the + issue of TCP's vulnerability to off-path third-party spoofing attacks + [9][10][48]. A variety of such attacks have been known for several + years, including sending RSTs, SYNs, and even ACKs in an attempt to + affect an existing connection or to load down servers. These attacks + often combine external knowledge (e.g., to indicate the IP addresses + to attack, the destination port number, and sometimes the Initial + Sequence Number (ISN)) with brute-force capabilities enabled by + modern computers and network bandwidths (e.g., to scan all source + ports or an entire window space). Overall, such attacks are + countered by the use of some form of authentication at the network + (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or other + layers. TCP already includes a weak form of such authentication in + its check of segment sequence numbers against the current receiver + window. Increases in the bandwidth-delay product for certain long + connections have sufficiently weakened this type of weak + authentication to make reliance on it inadvisable. + + + + + + + +Touch Informational [Page 4] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +2.1. Review of TCP Windows + + Before proceeding, it is useful to review the terminology and + components of TCP's windowing algorithm. TCP connections have three + kinds of windows [1][35]: + + o Send window (SND.WND): the latest send window size. + + o Receive window (RCV.WND): the latest advertised receive window + size. + + o Congestion window (CWND): the window determined by congestion + feedback that limits how much of RCV.WND can be in-flight in a + round-trip time. + + For TCP connections in most modern implementations, SND.WND and + RCV.WND are the size of the corresponding send and receive socket + buffers, and are configurable using socket buffer resizing commands. + + CWND determines how much data can be in transit in a round-trip time, + SND.WND determines how much data the sender is willing to store on + its side for possible retransmission due to loss, and RCV.WND + determines the ability of the receiver to accommodate that loss and + reorder received packets. CWND never grows beyond RCV.WND. + + High bandwidth-delay product networks need CWND to be sufficiently + large to accommodate as much data as can be in transit in a round + trip time; otherwise, their performance will suffer. As a result, it + is recommended that users and various automatic programs increase + RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay + product) [23][38]. + + As the bandwidth-delay product of the network increases, however, + such increases in the advertised receive window can cause increased + susceptibility to spoofing attacks, as the remainder of this document + shows. This assumes, however, that the receive window size (e.g., + via increased receive socket buffer configuration) is increased with + the increased bandwidth-delay product; if not, then connection + performance will degrade, but susceptibility to spoofing attacks will + increase only linearly (with the rate at which the attacker can send + spoofed packets), not as the square of the bandwidth. Note that + either increase depends on the receive window itself, and is + independent of the congestion state or amount of data transmitted. + + + + + + + + +Touch Informational [Page 5] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +2.2. Recent BGP Attacks Using TCP RSTs + + BGP represents a particular vulnerability to spoofing attacks because + it uses TCP connectivity to infer routability, so losing a TCP + connection with a BGP peer can result in the flushing of routes to + that peer [37]. + + Until six years ago, such connections were assumed difficult to + attack because they were described by a few comparatively obscure + parameters [20]. Most TCP connections are protected by multiple + levels of obfuscation except at the endpoints of the connection: + + o Both endpoint addresses are usually not well-known; although + server addresses are advertised, clients are somewhat anonymous. + + o Both port numbers are usually not well-known; the server's is + usually advertised (representing the service), but the client's is + typically sufficiently unpredictable to an off-path third-party. + + o Valid sequence number space is not well-known. + + o Connections are relatively short-lived and valid sequence space + changes, so any attempt to guess (e.g., by external knowledge or + brute force) the above information is unlikely to be useful. + + BGP represents an exception to the above criteria (though not the + only case). Both endpoints can be well-known, or guessed using hints + from part of an AS path. The destination port is typically fixed to + indicate the BGP service. The source port used by a BGP router is + sometimes fixed and advertised to enable firewall configuration; even + when not fixed, there are only approximately 65,000 valid source + ports, which thus may be exhaustively attacked. Connections are + long- lived, and, as noted before, some BGP implementations interpret + successive TCP connection failures as routing failures, discarding + the corresponding routing information. In addition, the valid + sequence number space once thought to provide some protection has + been significantly weakened by increasing advertised receive window + sizes. + +2.3. TCP RST Vulnerability + + TCP has a known vulnerability to third-party spoofed segments. SYN + flooding consumes server resources in half-open connections, + affecting the server's ability to open new connections [4][11]. ACK + spoofing can cause connections to transmit too much data too quickly, + creating network congestion and segment loss, causing connections to + slow to a crawl. In the most recent attacks on BGP, RSTs cause + connections to be dropped. As noted earlier, some BGP + + + +Touch Informational [Page 6] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + implementations interpret TCP connection termination, or a series of + such failures, as a network failure [37]. This causes routers to + drop the BGP routing information already exchanged, in addition to + inhibiting their ongoing exchanges, thus amplifying the impact of the + attack. The result can affect routing paths throughout the Internet. + + The dangerous effects of RSTs on TCP have been known for many years, + even when used by the legitimate endpoints of a connection. TCP RSTs + cause the receiver to drop all connection state; because the source + is not required to maintain a TIME_WAIT state, such a RST can cause + premature reuse of address/port pairs, potentially allowing segments + from a previous connection to contaminate the data of a new + connection, known as TIME_WAIT assassination [8]. In this case, + assassination occurs inadvertently as the result of duplicate + segments from a legitimate source, and can be avoided by blocking RST + processing while in TIME_WAIT. However, assassination can be useful + to deliberately reduce the state held at servers; this requires that + the source of the RSTs go into TIME_WAIT state to avoid such hazards, + and that RSTs are not blocked in the TIME_WAIT state [12]. + + Firewalls and load balancers, so-called 'middleboxes', sometimes emit + RSTs on behalf of transited connections to optimize server + performance, as noted in RFC 3360 [14]. This is effectively an on- + path RST attack in which the RSTs are sent for benign or beneficial + intent. There are numerous hazards with such use of RSTs, outlined + in that RFC. + +2.4. What Changed - the Ever-Opening Advertised Receive Window + + RSTs represent a hazard to TCP, especially when completely + unvalidated. Fortunately, there are a number of obfuscation + mechanisms that make it difficult for off-path third parties to forge + (spoof) valid RSTs, as noted earlier. We have already shown it is + easy to learn both endpoint addresses and ports for some protocols, + notably BGP. The final obfuscation is the segment sequence number. + + TCP segments include a sequence number, which enables out-of-order + receiver processing as well as duplicate detection. The sequence + number space is also used to manage congestion, and indicates the + index of the next byte to be transmitted or received. For RSTs, this + is relevant because legitimate RSTs use the next sequence number in + the transmitter window, and the receiver checks that incoming RSTs + have a sequence number in the expected receive window. Such + processing is intended to eliminate duplicate segments (somewhat moot + for RSTs, though), and to drop RSTs that were part of previous + connections. + + + + + +Touch Informational [Page 7] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + TCP uses two window mechanisms, a primary mechanism for reordering + and congestion control (which uses a space of 32 bits), and a + secondary mechanism that scales this window [23][35]. The valid + advertised receive window is a fraction, not to exceed approximately + half, of this space, or ~2 billion (2 * 10^9, i.e., 2E9 or 2 U.S. + billion). Under typical configurations, the majority of TCP + connections open to a very small fraction of this space, e.g., + 10,000-60,000(approximately 5-100 segments). This is because the + advertised receive window typically matches the receive socket buffer + size. It is recommended that this buffer be tuned to match the needs + of the connection, either manually or by automatic external means + [38]. + + On a low-loss path, the advertised receive window should be + configured to match the path bandwidth-delay product, including + buffering delays (assume 1 packet/hop) [38]. Many paths in the + Internet have end-to-end bandwidths of under 1 Mbps, latencies under + 100 ms, and are under 15 hops, resulting in fairly small advertised + receive windows as above (under 35,000 bytes). Under these + conditions, and further assuming that the initial sequence number is + suitably (pseudo-randomly) chosen, a valid guessed sequence number + would have odds of 1 in 57,000 of falling within the advertised + receive window. Put differently, a blind (i.e., off-path) attacker + would need to send 57,000 RSTs with suitably spaced sequence number + guesses within one round-trip time to successfully reset a + connection. At 1 Mbps, 57,000 (40 byte) RSTs would take only 20 + seconds to transmit, but this presumes that both IP addresses and + both ports are known. Absent knowledge of the source port, an off- + path spoofer would need to try at least the entire range of 49152- + 65535, or 16,384 different ports, resulting in an attack that would + take over 91 hours. Because most TCP connections are comparatively + short-lived, even this moderate variation in the source port is + sufficient for such environments, although further port randomization + may be recommended [29]. + + Recent use of high bandwidth paths of 10 Gbps and higher results in + bandwidth-delay products over 125 MB -- approximately 1/10 of TCP's + overall maximum advertised receive window size (i.e., assuming the + receive socket buffers are increased as much as possible) excluding + scale, assuming the receiver allocates sufficient buffering (as + discussed in Section 2). Even under networks that are ten times + slower (1 Gbps), the active advertised receive window covers 1/100th + of the overall window size. At these speeds, it takes only 10-100 + packets, or less than 32 microseconds, to correctly guess a valid + sequence number and kill a connection. A table of corresponding + exposure to various amounts of RSTs is shown below, for various line + rates, assuming the more conventional 100-ms latencies (though even + 100 ms is large for BGP cases): + + + +Touch Informational [Page 8] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + BW BW*delay RSTs needed Time needed + ------------------------------------------------------------ + 10 Gbps 125 MB 35 1 us (microsecond) + 1 Gbps 12.5 MB 344 110 us + 100 Mbps 1.25 MB 3,436 10 ms (millisecond) + 10 Mbps 0.125 MB 34,360 1 second + 1 Mbps 0.0125 MB 343,598 2 minutes + 100 Kbps 0.00125 MB 3,435,974 3 hours + + Figure 1: Time needed to kill a connection + + This table demonstrates that the effect of bandwidth on the + vulnerability is squared; for every increase in bandwidth, there is a + linear decrease in the number of sequence number guesses needed, as + well as a linear decrease in the time needed to send a set of + guesses. Notably, as inter-router link bandwidths approach 1 Mbps, + an 'exhaustive' attack becomes practical. Checking that the RST + sequence number is somewhere in the advertised receive window, out of + the overall maximum receive window (2^32), is an insufficient + obfuscation. + + Note that this table makes a number of assumptions: + + 1. The overall bandwidth-delay product is relatively fixed. + + 2. Traffic losses are negligible (insufficient to affect the + congestion window over the duration of most of the connection). + + 3. The advertised receive window is a large fraction of the overall + maximum receive window size, e.g., because the receive socket + buffers are set to match a large bandwidth-delay product. + + 4. The attack bandwidth is similar to the end-to-end path bandwidth. + + Of these assumptions, the last two are more notable. The issue of + receive socket buffers was discussed in Section 2. Figure 1 + summarized the time to a successful attack based on large advertised + receive windows, but many current commercial routers have limits of + 128 KB for large devices, 32 KB for medium, and as little as 4 KB for + modest ones. Figure 2 shows the time and bandwidths needed to + accomplish an attack on BGP sessions in the time shown for 100-ms + latencies; for even short-range network latencies (10 ms), these + sessions can be still be attacked over short timescales (minutes to + hours). + + + + + + + +Touch Informational [Page 9] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + Receive + BW Buffer Size RSTs needed Time needed + ------------------------------------------------------------ + 10 Mbps 0.128 MB 33,555 1 second + 3 Mbps 0.032 MB 134,218 40 seconds + 300 Kbps 0.004 MB 1,073,742 1 hour + + Figure 2: Time needed to kill a connection with limited buffers + + The issue of the attack bandwidth is considered reasonable as + follows: + + 1. RSTs are substantially easier to send than data; they can be + precomputed and they are smaller than data packets (40 bytes). + + 2. Although susceptible connections use somewhat less ubiquitous + high-bandwidth paths, the attack may be distributed, at which + point only the ingress link of the attack is the primary + limitation. + + 3. For the purposes of the above table, we assume that the ingress at + the attack has the same bandwidth as the path, as an + approximation. + + The previous sections discussed the nature of the recent attacks on + BGP due to the vulnerability of TCP to RST spoofing attacks, due + largely to recent increases in the fraction of the TCP advertised + receive window space in use for a single, long-lived connection. + +3. Proposed Solutions and Mitigations + + TCP currently authenticates received RSTs using the address and port + pair numbers, and checks that the sequence number is inside the valid + receiver window. The previous section demonstrated how TCP has + become more vulnerable to RST spoofing attacks due to the increases + in the receive window size. There are a number of current and + proposed solutions to this vulnerability, all attempting to provide + evidence that a received RST is legitimate. + +3.1. Transport Layer Solutions + + The transport layer represents the last place that segments can be + authenticated before they affect connection management. TCP has a + variety of current and proposed mechanisms to increase the + authentication of segments, protecting against both off-path and on- + path third-party spoofing attacks. Other transport protocols, such + as SCTP and DCCP, also have limited antispoofing mechanisms. + + + + +Touch Informational [Page 10] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +3.1.1. TCP MD5 Authentication + + An extension to TCP supporting MD5 authentication was developed in + 1998 specifically to authenticate BGP connections (although it can be + used for any TCP connection) [20]. The extension relies on a pre- + shared secret key to authenticate the entire TCP segment, including + the data, TCP header, and TCP pseudo-header (certain fields of the IP + header). All segments are protected, including RSTs, to be accepted + only when their signature matches. This option, although widely + deployed in Internet routers, is considered undeployable for + widespread use because the need for pre-shared keys [3][30]. It + further is considered computationally expensive for either hosts or + routers due to the overhead of MD5 [43][44]. + + There are also concerns about the use of MD5 due to recent collision- + based attacks [22]. Similar concerns exist for SHA-1, and the IETF + is currently evaluating how these attacks impact the recommendation + for using these hashes, both in TCP/MD5 and in the IPsec suite. For + the purposes of this discussion, the particular algorithm used in + either protocol suite is not the focus, and there is ongoing work to + allow TCP/MD5 to evolve to a more general TCP security option + [6][47]. + +3.1.2. TCP RST Window Attenuation + + A recent proposal extends TCP to further constrain received RST to + match the expected next sequence number [36]. This restores TCP's + resistance to spurious RSTs, effectively limiting the receive window + for RSTs to a single number. As a result, an attacker would need to + send 2^32 different packets to brute-force guess the sequence number + (worst case, the average would be half that); this makes TCP's + vulnerability to attack independent of the size of the receive window + (RCV.WND). The extension further modifies the RST receiver to react + to incorrectly-numbered RSTs, by sending a zero-length ACK. If the + RST source is legitimate, upon receipt of an ACK, the closed source + would presumably emit a RST with the sequence number matching the + ACK, correctly resetting the intended recipient. This modification + changes TCP's control processing, adding to its complexity and thus + potentially affecting its correctness (in contrast to adding MD5 + signatures, which is orthogonal to TCP control processing + altogether). For example, there may be complications between RSTs of + different connections between the same pair of endpoints because RSTs + flush the TIME-WAIT (as mentioned earlier). Further, this proposal + modifies TCP so that, under some circumstances, a RST causes a reply + (an ACK), in violation of generally accepted practice, if not gentle + recommendation -- although this can be omitted, allowing timeouts to + suffice. The advantage to this proposal is that it can be deployed + incrementally and has benefit to the endpoint on which it is + + + +Touch Informational [Page 11] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + deployed. The other advantage to this proposal is that the window + attenuation described here makes the vulnerability to spoofed RST + packets independent of the size of the receive window. + + A variant of this proposal uses a different value to attenuate the + window of viable RSTs. It requires RSTs to carry the initial + sequence number rather than the next expected sequence number, i.e., + the value negotiated on connection establishment [42][49]. This + proposal has the advantage of using an explicitly negotiated value, + but at the cost of changing the behavior of an unmodified endpoint to + a currently valid RST. It would thus be more difficult, without + additional mechanism, to deploy incrementally. + + Another variant of this proposal involves increasing TCP's window + space, rather than decreasing the valid range for RSTs, i.e., + increasing the sequence space from 32 bits to 64 bits. This has the + equivalent effect -- the ratio of the valid sequence numbers for any + segment to the overall sequence number space is significantly + reduced. The use of the larger space, as with current schemes to + establish weak authentication using initial sequence numbers (ISNs), + is contingent on using suitably random values for the ISN. Such + randomness adds additional complexity to TCP both in specification + and implementation, and provides only very weak authentication. Such + a modification is not obviously backward compatible, and would be + thus difficult to deploy. + + A converse variant of increasing TCP's window space is to decrease + the receive window (RCV.WND) explicitly, which would further reduce + the effectiveness of spoofed RSTs with random sequence numbers. This + alternative may reduce the throughput of the connection, if the + advertised receive window is smaller than the bandwidth-delay product + of the connection. + +3.1.3. TCP Timestamp Authentication + + Another way to authenticate TCP segments is via its timestamp option, + using the value as a sort of authentication [34]. This requires that + the receiver TCP discard segments whose timestamp is outside the + accepted window, which is derived from the timestamps of other + packets from the same connection. This technique uses an existing + TCP option, but also requires modified TCP control processing (with + the same caveats) and may be difficult to deploy incrementally + without further modifications. Additionally, the timestamp value may + be easier to guess because it can be derived predictably, either + assuming it represents actual time at the host, or by probing the + host using unrelated benign traffic. + + + + + +Touch Informational [Page 12] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +3.1.4. Other TCP Cookies + + All of the above techniques are variants of cookies, otherwise + meaningless data whose value is used to validate the packet. In the + case of MD5 checksums, the cookie is computed based on a shared + secret. Note that even a signature can be guessed, and presents a 1 + in 2^(signature length) probability of attack. The primary + difference is that MD5 signatures are effectively one-time cookies, + not predictable based on on-path snooping, because they are dependent + on packet data and thus do not repeat. Window attenuation sequence + numbers can be guessed by snooping the sequence number of current + packets of an existing connection, and timestamps can be guessed even + less directly, either by separate benign connections or by assuming + they roughly correlate to local time. These variants of cookies are + similar in spirit to TCP SYN cookies, again patching a vulnerability + to off-path third-party spoofing attacks based on a (fairly weak, + excepting MD5) form of authentication. Another form of cookie is the + source port itself, which can be randomized but provides only 16 bits + of protection (65,000 combinations), which may be exhaustively + attacked. This can be combined with destination port randomization + as well, but that would require a separate coordination mechanism (so + both parties know which ports to use), which is equivalent to (and as + infeasible for large-scale deployments as) exchanging a shared secret + [39]. + +3.1.5. Other TCP Considerations + + The analysis of the potential for RST spoofing above assumes that the + advertised receive window is opened to the maximum extent suggested + by the bandwidth-delay product of the end-to-end path, and that the + window is opened to an appreciable fraction of the overall sequence + number space. As noted earlier, for most common cases, connections + are too brief or over bandwidths too low for such a large window to + be useful. Expanding TCP's sequence number space is a direct way to + further avoid such vulnerability, even for long connections over + emerging bandwidths. If either manual tuning or automatic tuning of + the advertised receive window (via receive buffer tuning) is not + provided, this is not an issue (although connection performance will + suffer) [38]. + + It may be sufficient for the endpoint to limit the advertised receive + window by deliberately leaving it small. If the receive socket + buffer is limited, e.g., to the ubiquitous default of 64 KB, the + advertised receive window will not be as vulnerable even for very + long connections over very high bandwidths. The vulnerability will + grow linearly with the increased network speed, but not as the + square. The consequence is lower sustained throughput, where only + one window's worth of data per round-trip time (RTT) is exchanged. + + + +Touch Informational [Page 13] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + This will keep the connection open longer; for long-lived connections + with continuous sourced data, this may continue to present an attack + opportunity, albeit a sparse and slow-moving target. For the most + recent case where BGP data is being exchanged between Internet + routers, the data is bursty and the aggregate traffic may be small + (i.e., unlikely to cover a substantial portion of the sequence space, + even if long-lived), so smaller advertised receive windows (via small + receiver buffers) may, in some cases, sufficiently address the + immediate problem. This assumes that the routing tables can be + exchanged quickly enough with bandwidth reduced due to the smaller + buffers, or perhaps that the advertised receive window is opened only + during a large burst exchange (e.g., via some other signal between + the two routers, or a time-based signal, though either would be + nonstandard). + +3.1.6. Other Transport Protocol Solutions + + Segment authentication has been addressed at the transport layer in + other protocols. Both SCTP and DCCP include cookies for connection + establishment and use them to authenticate a variety of other control + messages [28][41]. The inclusion of such mechanism at the transport + protocol, although emerging as standard practice, complicates the + design and implementation of new protocols [32]. As new attacks are + discovered (SYN floods, RSTs, etc.), each protocol must be modified + individually to compensate. A network solution may be more + appropriate and efficient. + + It should be noted that RST attacks, which rely on brute-force, are + relatively easy for intrusion detection software to detect at the TCP + layer. Any connection that receives a large number of invalid -- + outside-window -- RSTs might have subsequent RSTs blocked, to defeat + such attacks. This would have the side-effect of blocking legitimate + RSTs to that connection, which might then interfere with cleaning up + the transport state between the endpoint peers. This side-effect, + coupled with the increased monitoring load, might render such + solutions undesirable in the general case, but they might usefully be + applied to special cases, e.g., for BGP for routers. + +3.2. Network Layer (IP) Solutions + + There are two primary variants of network layer solutions to + spoofing: address filtering and IPsec. Address filtering is an + indirect system that relies on other parties to filter packets sent + upstream of an attack, but does not necessarily require participation + of the packet source. IPsec requires cooperation between the + endpoints wanting to avoid attack on their connection, which + currently involves preexisting shared knowledge of either a shared + key or shared certificate authority. + + + +Touch Informational [Page 14] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +3.2.1. Address Filtering + + Address filtering is often proposed as an alternative to protocol + mechanisms to defeat IP source address spoofing [2][13]. Address + filtering restricts traffic from downstream sources across transit + networks based on the IP source address. A kind of filtering already + occurs at the endpoints of a connection, because attack messages must + match the socket pair to succeed; again, note that such attacks + require knowing the entire socket pair, and are unlikely except in + particular cases. This section discusses filtering based on address + only, typically done at the borders of an AS. + + It can also restrict core-to-edge paths to reject traffic that should + have originated further toward the edge. It cannot restrict traffic + from edges lacking filtering through the core to a particular edge. + As a result, each border router must perform the appropriate + filtering for overall protection to result; failure of any border + router to filter defeats the protection of all participants inside + the border, and potentially those outside as well. Address filtering + at the border can protect those inside the border from some kinds of + spoofing, i.e., connections among those inside a border, because only + interior addresses should originate inside the border. It cannot, + however, protect connections including endpoints outside the border + (i.e., those that traverse the AS boundary) except to restrict where + the traffic enters from, e.g., if it expected from one AS and not + another. + + As a result, address filtering is not a local solution that can be + deployed to protect communicating pairs, but rather relies on a + distributed infrastructure of trusted gateways filtering forged + traffic where it enters the network. It is not feasible for local, + incremental deployment, but may be applicable to connections among + those inside the protected border in some scenarios. Applying + filtering can also be useful to reduce the network load of spoofed + traffic [31]. + + A more recent variant of address filtering checks the IP TTL (Time to + Live) field, relying on the TTL set by the other end of the + connection [15]. This technique has been used to provide filtering + for BGP. It assumes the connection source TTL is set to 255; packets + at the receiver are checked for TTL=255, and others are dropped. + This restricts traffic to one hop upstream of the receiver (i.e., a + BGP router), but those hops could include other user programs at + those nodes (e.g., the BGP router's peer) or any traffic those nodes + accept via tunnels -- because tunnels need not decrement TTLs, + notably for "bump in the wire" (BITW) or BITW-equivalent scenarios + [33] (see also Section 5.1 of [15] and [16]). TTL filtering works + only where all traffic from the other end of the tunnel is trusted, + + + +Touch Informational [Page 15] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + i.e., where it does not originate or transit spoofed traffic. The + use of TTL rather than link or network security also assumes an + untampered point-to-point link, where no other traffic can be spoofed + onto a link. + + This method of filtering works best where traffic originates one hop + away, so that the address filtering is based on the trust of only + directly-connected (tunneled or otherwise) nodes. Like conventional + address filtering, this reduces spoofing traffic in general, but is + not considered a reliable security mechanism because it relies on + distributed filtering (e.g., the fact that upstream nodes do not + terminate tunnels arbitrarily). + +3.2.2. IPsec + + TCP is susceptible to RSTs, but also to other off-path and on-path + spoofing attacks, including SYN attacks. Other transport protocols, + such as UDP and RTP are equally susceptible. Although emerging + transport protocols attempt to defeat such attacks at the transport + layer, such attacks take advantage of network layer identity + spoofing. The packet is coming from an endpoint that is spoofing + another endpoint, either upstream or somewhere else in the Internet. + IPsec was designed specifically to establish and enforce + authentication of a packet's source and contents in order to most + directly and explicitly address this security vulnerability. + + The larger problem with IPsec is that of key distribution and use. + IPsec is often cumbersome, and has only recently been supported in + many end-system operating systems. More importantly, it relies on + preshared keys, signed X.509 certificates, or a trusted third-party + (e.g., Kerberos) key infrastructure to establish and exchange keying + information (e.g., via IKE). Each of these issues presents + challenges when using IPsec to secure traffic to a well-known server, + whose clients may not support IPsec or may not have registered with a + previously-known certificate authority (CA). + + These keying challenges are being addressed in the IETF in ways that + will enable servers secure associations with other parties without + advance coordination [45][46]. This can be especially useful for + publicly-available servers, or for protecting connections to servers + that -- for whatever reason -- have not or will not deploy + conventional IPsec certificates (i.e., core Internet BGP routers). + + + + + + + + + +Touch Informational [Page 16] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +4. ICMP + + Just as spoofed TCP packets can terminate a connection, so too can + spoofed ICMP packets. ICMP can be used to launch a variety of + attacks on TCP including connection resets, path-MTU attacks, and can + also be used to attack the host with non-TCP 'ping of death' and + 'smurf attacks', etc. [40]. ICMP thus represents a substantial + threat to TCP, but this is not the focus of this document, although a + number of protections are discussed below because some are comparable + to TCP anti-spoofing techniques. Note also that ICMP attacks on TCP + assume that the socket pair is known by the attacker, which is + unlikely except for a subset of services between pairs of widely- + known endpoints. + + TCP headers can be included inside certain ICMP messages [7]. There + have been recent suggestions to validate the sequence number of TCP + headers when they occur inside ICMP messages [18]. This sequence + checking is similar to checks that would occur for conventional data + packets in TCP, but is being proposed in the spirit of the RST window + attenuation described in Section 3.1.2. + + Some such checks may be reasonable, especially where they parallel + the validations already performed by TCP processing, notably where + they emulate the semantics of such processing. For example, the TCP + checksum should be validated (if the entire TCP segment is contained + in the ICMP message) before any fields of the TCP header are + examined, to avoid reacting to corrupted packets. Similarly, if the + TCP MD5 option is present, its signature should probably be validated + before considering the contents of the message. Such validation can + ensure that the packet was not corrupted prior to the ICMP generation + (checksum), that the packet was one sent by the source (IPsec or + TCP/MD5 authenticated), or that the packet was not in the network for + an excess of 2*MSL (valid sequence number). + + ICMP presents a particular challenge because some messages can reset + a connection more easily -- with less validation -- than even some + spoofed TCP segments. One other proposed alternative is to change + TCP's reaction to ICMPs after a connection is established; that may + leave TCP susceptible during connection establishment and modifies + TCP's reaction to certain valid network events [19]. This considers + the context-sensitivity of ICMP messages, as does IPsec in some + tunneled configurations, but the recommendations are ambiguous + regarding such filtering [27]. + + Ultimately, requiring TCP ICMP messages to be 'in window' may be + insufficient protection, as this document shows for spoofed data. + ICMP packets can be authenticated when originating at known, trusted + endpoints, such as endpoints of connections or routers in known + + + +Touch Informational [Page 17] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + domains with preexisting IPsec associations. Unfortunately, they + also can originate at other places in the network. In addition, some + networks filter all ICMP packets because validation may not be + possible, especially because they can be injected from anywhere in a + network, and so cannot be easily and locally address filtered [27]. + As a result, they are not addressed separately in the issues or + security considerations of this document further. + +5. Issues + + There are a number of existing and proposed solutions addressing the + vulnerability of transport protocols in general (and TCP in specific) + to off-path third-party spoofing attacks. As shown, these operate at + the transport or network layer. Transport solutions require separate + modification of each transport protocol, addressing network identity + spoofing separately in the context of each transport association. + Network solutions require distributed coordination (filtering) or can + be computationally intensive and require pervasive registration of + certificate authorities with every possible endpoint + (authentication). This section explains these observations further. + +5.1. Transport Layer (e.g., TCP) + + Transport solutions rely on shared cookies to authenticate segments, + including data, transport header, and even pseudo-header (e.g., fixed + portions of the outer IP header in TCP). Because the Internet relies + on stateless network protocols, it makes sense to rely on state + establishment and maintenance available in some transport layers not + only for the connection but for authentication state. Three-way + handshakes and heartbeats can be used to negotiate authentication + state in conjunction with connection parameters, which can be stored + with connection state easily. + + As noted earlier, transport layer solutions require separate + modification of all transport protocols to include authentication. + Not all transport protocols support negotiated endpoint state (e.g., + UDP), and legacy protocols have been notoriously difficult to safely + augment. Not all authentication solutions are created equal, either, + and relying on a variety of transport solutions exposes end-systems + to increased potential for incorrectly specified or implemented + solutions. Transport authentication has often been developed piece- + wise, in response to specific attacks, e.g., SYN cookies and RST + window attenuation [4][36]. + + Transport layer solutions are not only per-protocol, but often per- + connection. This has both advantages and drawbacks. One advantage + to transport layer solutions is that they can protect the transport + protocol when lower layers have failed, e.g., due to bugs in + + + +Touch Informational [Page 18] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + implementation. TCP already includes a variety of packet validation + mechanisms to protect in these cases, e.g., checking that RSTs are + in-window. More strict checks can increase the protections provided, + e.g., to protect against misaddressed RSTs that end up in-window (via + TCPsecure) or to protect against connection interruption due to RSTs, + SYNs, or data injection from misaddressed packets (TCP/MD5) [36]. + + Another advantage is that transport layer protections can be more + specifically limited to a particular connection. Because each + connection negotiates its state separately, that state can be more + specifically tied to that connection. This is both an advantage and + a drawback. It can make it easier to tie security to an individual + connection, although in practice a shared secret or certificate will + generally be shared across multiple connections. + + As a drawback, each transport connection needs to negotiate and + maintain authentication state separately. Some overhead is not + amortized over multiple connections, e.g., overheads in packet + exchanges, whereas other overheads are not amortized over different + transport protocols, e.g., design and implementation complexity -- + both as would be the case in a network layer solution. Because the + authentication happens later in packet processing than is required, + additional endpoint resources may be needlessly consumed, e.g., in + demultiplexing received packets, indexing connection identifiers, and + continuing to buffer spoofed packets, etc., only to be dropped later + at the transport layer. + +5.2. Network Layer (IP) + + A network layer solution avoids the hazards of multiple transport + variants, using a single shared endpoint authentication mechanism + early in receiver packet processing to discard unauthenticated + packets at the network layer instead. This defeats spoofing entirely + because spoofing involves masquerading as another endpoint, and + network layer security validates the endpoint as the source of the + packets it emits. Such a network level solution protects all + transport protocols as a result, including both legacy and emerging + protocols, and reduces the complexity of these protocols as well. A + shared solution also reduces protocol overhead, and decouples the + management (and refreshing) of authentication state from that of + individual transport connections. Finally, a network layer solution + protects not only the transport layer but the network layer as well, + e.g., from IGMP, and some kinds of ICMP (Section 4), spoofing + attacks. + + The IETF Proposed Standard protocol for network layer authentication + is IPsec [27]. IPsec specifies the overall architecture, including + header authentication (AH) [25] and encapsulation (ESP) modes [26]. + + + +Touch Informational [Page 19] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + AH authenticates both the IP header and IP data, whereas ESP + authenticates only the IP data (e.g., transport header and payload). + AH is being phased out since ESP is more efficient and the Security + Parameters Index (SPI) includes sufficient information to verify the + IP header anyway [27]. These two modes describe the security applied + to individual packets within the IPsec system; key exchange and + management is performed either out-of-band (via pre-shared keys) or + by an automated key exchange protocol, e.g., IKE [24]. + + IPsec already provides authentication of an IP header and its data + contents sufficient to defeat both on-path and off-path third-party + spoofing attacks. IKE can configure authentication between two + endpoints on a per-endpoint, per-protocol, or per-connection basis, + as desired. IKE also can perform automatic periodic re-keying, + further defeating crypto-analysis based on snooping (clandestine data + collection). The use of IPsec is already commonly strongly + recommended for protected infrastructure. + + Existing IPsec is not appropriate for many deployments. It is + computationally intensive both in key management and individual + packet authentication [43]. This computational overhead can be + prohibitive, and so often requires additional hardware, especially in + commercial routers. As importantly, IKE is not anonymous; keys can + be exchanged between parties only if they trust each other's X.509 + certificates, trust some other third-party to help with key + generation (e.g., Kerberos), or pre-share a key. These certificates + provide identification (the other party knows who you are) only where + the certificates themselves are signed by certificate authorities + (CAs) that both parties already trust. To a large extent, the CAs + themselves are the pre-shared keys that help IKE establish security + association keys, which are then used in the authentication + algorithms. + + Alternative mechanisms are under development to address this + limitation, to allow publicly-accessible servers to secure + connections to clients not known in advance, or to allow unilateral + relaxation of identity validation so that the remaining protections + of IPsec can be made available [45][46]. In particular, these + mechanisms can prevent a client (but without knowing who that client + is) from being affected by spoofing from other clients, even when the + attackers are on the same communications path. + + IPsec, although widely available both in commercial routers and + commodity end-systems, is not often used except between parties that + already have a preexisting relationship (employee/employer, between + two ISPs, etc.). Servers to anonymous clients (e.g., customer/ + business) or more open services (e.g., BGP, where routers may have + large numbers of peers) are unmanageable, due to the breadth and flux + + + +Touch Informational [Page 20] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + of CAs. New endpoints cannot establish IPsec associations with such + servers unless their own certificate is signed by a CA already + trusted by the server. Different servers -- even within the same + overall system (e.g., BGP) -- often cannot or will not trust + overlapping subsets of CAs in general. + +5.3. Application Layer + + There are a number of application layer authentication mechanisms, + often implicit within end-to-end encryption. Application layer + security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) + provides the ultimate protection of application data from all + intermediaries, including network routers as well as exposure at + other layers in the end-systems. This is the only way to ultimately + protect the application data. + + Application authentication cannot protect either the network or + transport protocols from spoofing attacks, however. Spoofed packets + interfere with network processing or reset transport connections + before the application checks the data. Authentication needs to + winnow these packets and drop them before they interfere at these + lower layers. + + An alternate application layer solution would involve resilience to + reset connections. If the application can recover from such + connection interruptions, then such attacks have less impact. + Unfortunately, attackers still affect the application, e.g., in the + cost of restarting connections, delays until connections are + restarted, or increased connection establishment messages on the + network. Some applications -- notably BGP -- even interpret TCP + connection reliability as an indicator of route path stability, which + is why attacks on BGP have such substantial consequences. + +5.4. Link Layer + + Link layer security operates separately on each hop of an Internet. + Such security can be critical in protecting link resources, such as + bandwidth and link management protocols. Protection at this layer + cannot suffice for network or transport layers, because it cannot + authenticate the endpoint source of a packet. Link authentication + ensures only the source of the current link hop where it is examined. + +5.5. Issues Discussion + + The issues raised in this section suggest that there are challenges + with all solutions to transport protection from spoofing attacks. + This raises the potential need for alternate security levels. While + it is already widely recognized that security needs to occur + + + +Touch Informational [Page 21] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + simultaneously at many protocol layers, there also may be utility in + supporting a variety of strengths at a single layer. For example, + IPsec already supports a variety of algorithms (MD5, SHA1, etc., for + authentication), but always assumes that: + + 1. The entire body of the packet is secured. + + 2. Security associations are established only where identity is + authenticated by a known certificate authority or other pre-shared + key. + + 3. Both on-path and off-path third-party spoofing attacks must be + defeated. + + These assumptions are prohibitive, especially in many cases of + spoofing attacks. For spoofing, the primary issue is whether packets + are coming from the same party the server can reach. Only the IP + header is fundamentally in question, so securing the entire packet + (1) is computational overkill. It is sufficient to authenticate the + other party as "a party you have exchanged packets with", rather than + establishing their trusted identity ("Bill" vs. "Bob") as in (2). + Finally, many cookie systems use clear-text (unencrypted), fixed + cookie values, providing reasonable (1 in 2^{cookie-size}) protection + against off-path third-party spoof attacks, but not addressing on- + path attacks at all. Such potential solutions are discussed in the + Better Than Nothing Security (BTNS) documents [5][45][46]. Note also + that NULL Encryption in IPsec applies a variant of this cookie, where + the SPI is the cookie, and no further encryption is applied [17]. + +6. Security Considerations + + This entire document focuses on increasing the security of transport + protocols and their resistance to spoofing attacks. Security is + addressed throughout. + + This document describes a number of techniques for defeating spoofing + attacks. Those relying on clear-text cookies, either explicit or + implicit (e.g., window sequence attenuation) do not protect from on- + path spoofing attacks, since valid values can be learned from prior + traffic. Those relying on true authentication algorithms are + stronger, protecting even from on-path attacks, because the + authentication hash in a single packet approaches the behavior of + "one-time" cookies. + + The security of various levels of the protocol stack is addressed. + Spoofing attacks are fundamentally identity masquerading, so we + believe the most appropriate solutions defeat these at the network + layer, where end-to-end identity lies. Some transport protocols + + + +Touch Informational [Page 22] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + subsume endpoint identity information from the network layer (e.g., + TCP pseudo-headers), whereas others establish per-connection identity + based on exchanged nonces (e.g., SCTP). It is reasonable, if not + recommended, to address security at all layers of the protocol stack. + + Note that Network Address Translators (NATs) and other middleboxes + complicate the design and deployment of techniques to defeat spoofing + attacks. Devices such as these, that modify IP and/or TCP headers + in-transit, generate traffic equivalent to a spoofing attack, and + thus should be inhibited by antispoofing mechanisms. Details of + these middlebox-related problems are out of scope for this document, + but issues thereof are addressed in RFCs and emerging documents that + discuss the interactions between such devices and the Internet + architecture, e.g., [21]. Fortunately, many of the most critical + TCP-based connections -- in particular, those supporting routing + protocols like BGP -- do not traverse such middleboxes, and are not + affected by this limitation. + +7. Conclusions + + This document describes the details of the recent BGP spoofing + attacks involving spurious RSTs, which could be used to shutdown TCP + connections. It summarizes and discusses a variety of current and + proposed solutions at various protocol layers. + +8. Acknowledgments + + This document was inspired by discussions in the TCPM WG + <http://www.ietf.org/html.charters/tcpm-charter.html> about the + recent spoofed RST attacks on BGP routers, including R. Stewart's + document (whose author list has since evolved) [36][42]. The + analysis of the attack issues, alternate solutions, and the anonymous + security proposed solutions were the result of discussions on that + list as well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. + Wang. R. Atkinson suggested the UDP variant of TCP/MD5, P. Goyette + suggested using the ISN to seed TCP/MD5, and L. Wood suggested using + the ISN to validate RSTs. Other improvements are due to the input of + various members of the IETF's TCPM WG, notably detailed feedback from + F. Gont, P. Savola, and A. Hoenes. + + This document was prepared using 2-Word-v2.0.template.dot. + + + + + + + + + + +Touch Informational [Page 23] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +9. Informative References + + [1] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion + Control", RFC 2581, April 1999. + + [2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + [3] Bellovin, S. and A. Zinin, "Standards Maturity Variance + Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 + Specification", RFC 4278, January 2006. + + [4] Bernstein, D., "SYN cookies", 1997, + <http://cr.yp.to/syncookies.html>. + + [5] Better Than Nothing Security [BTNS] WG web pages, + <http://www.postel.org/anonsec>. + + [6] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. + Wheeler, "Authentication for TCP-based Routing and Management + Protocols", Work in Progress, February 2007. + + [7] Braden, R., "Requirements for Internet Hosts - Communication + Layers", STD 3, RFC 1122, October 1989. + + [8] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, + May 1992. + + [9] CERT alert: "Technical Cyber Security Alert TA04-111A: + Vulnerabilities in TCP", April 20, 2004, + <http://www.us-cert.gov/cas/techalerts/TA04-111A.html>. + + [10] Convery, S., and M. Franz, "BGP Vulnerability Testing: + Separating Fact from FUD", 2003, + <http://www.nanog.org/mtg-0306/pdf/franz.pdf>. + + [11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", + Work in Progress, May 2007. + + [12] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP + and Its Effect on Busy Servers", Proc. Infocom 1999, pp. 1573- + 1583, Mar. 1999. + + [13] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + + + + +Touch Informational [Page 24] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + [14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP + 60, RFC 3360, August 2002. + + [15] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL + Security Mechanism (GTSM)", RFC 3682, February 2004. + + [16] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. + Pignataro, "The Generalized TTL Security Mechanism (GTSM)", + Work in Progress, June 2007. + + [17] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its + Use With IPsec", RFC 2410, November 1998. + + [18] Gont, F., "ICMP attacks against TCP", Work in Progress, May + 2007. + + [19] Gont, F., "TCP's Reaction to Soft Errors", Work in Progress, + June 2007. + + [20] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 + Signature Option", RFC 2385, August 1998. + + [21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the + IP Network Address Translator", RFC 3027, January 2001. + + [22] Housley, R., Post to IETF Discussion mailing list regarding his + IETF 64 Security Area presentation, + ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24, + 2005, <http://www1.ietf.org/ + mail-archive/ietf/Current/maillist.html>. + + [23] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for + High Performance", RFC 1323, May 1992. + + [24] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC + 4306, December 2005. + + [25] Kent, S., "IP Authentication Header", RFC 4302, December 2005. + + [26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, + December 2005. + + [27] Kent, S. and K. Seo, "Security Architecture for the Internet + Protocol", RFC 4301, December 2005. + + [28] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion + Control Protocol (DCCP)", RFC 4340, March 2006. + + + + +Touch Informational [Page 25] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + [29] Larsen, M., and F. Gont, "Port Randomization", Work in + Progress, February 2007. + + [30] Leech, M., "Key Management Considerations for the TCP MD5 + Signature Option", RFC 3562, July 2003. + + [31] Moore, D., G. Voelker, and S. Savage, "Inferring Internet + Denial-of-Service Activity", Proc. Usenix Security Symposium, + Aug. 2001. + + [32] O'Malley, S. and L. Peterson, "TCP Extensions Considered + Harmful", RFC 1263, October 1991. + + [33] Perkins, C., "IP Encapsulation within IP", RFC 2003, October + 1996. + + [34] Poon, K., "Use of TCP timestamp option to defend against blind + spoofing attack", Work in Progress, October 2004. + + [35] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + September 1981. + + [36] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's + Robustness to Blind In-Window Attacks", Work in Progress, July + 2007. + + [37] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border + Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [38] Semke, J., J. Mahdavi, and M. Mathis, "Automatic TCP Buffer + Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume + 28, number 4, Oct. 1998. + + [39] Shepard, T., "Reassign Port Number option for TCP", Work in + Progress, July 2004. + + [40] Shirey, R., "Internet Security Glossary, Version 2", Work in + Progress, November 2006. + + [41] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, + H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. + Paxson, "Stream Control Transmission Protocol", RFC 2960, + October 2000. + + [42] TCPM: IETF TCPM Working Group and mailing list, + <http://www.ietf.org/html.charters/tcpm-charter.html>. + + [43] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995. + + + +Touch Informational [Page 26] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + + [44] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995, + pp. 77-86, Mar. 1999. + + [45] Touch, J., "ANONsec: Anonymous Security to Defend Against + Spoofing Attacks", Work in Progress, May 2004. + + [46] Touch, J., Black, D., and Y. Wang, "Problem and Applicability + Statement for Better Than Nothing Security (BTNS)", Work in + Progress, February 2007. + + [47] Touch, J. and A. Mankin, "The TCP Simple Authentication + Option", Work in Progress, July 2007. + + [48] Watson, P., "Slipping in the Window: TCP Reset attacks", + Presentation at 2004 CanSecWest, + <http://cansecwest.com/csw04archive.html>. + + [49] Wood, L., Post to TCPM mailing list regarding use of ISN in + RSTs, ID=Pine.GSO.4.50.0404232249570.5889- + 100000@argos.ee.surrey.ac.uk, Apr. 23, 2004, + <http://www1.ietf.org/mail-archive/web/tcpm/current/ + msg00213.html>. + +Author's Addresses + + Joe Touch + USC/ISI + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + U.S.A. + + Phone: +1 (310) 448-9151 + Fax: +1 (310) 448-9300 + EMail: touch@isi.edu + URI: http://www.isi.edu/touch + + + + + + + + + + + + + + + + +Touch Informational [Page 27] + +RFC 4953 Defending TCP Against Spoofing Attacks July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Touch Informational [Page 28] + |