Network Working Group R. Stewart Internet-Draft M. Dalal
Internet-Draft EditorExpires: November 19, 2005 May 18, 2005August 17, 2006 Editor February 13, 2006 Improving TCP's Robustness to Blind In-Window Attacks draft-ietf-tcpm-tcpsecure-03.txtdraft-ietf-tcpm-tcpsecure-04.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667.By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with sectionSection 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 19, 2005.August 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005).(2006). Abstract A recent study indicates that some types of TCP (RFC793 )connections have an increased vulnerability to spoofed packet injection attacks than previously believed [SITW]. TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is widely deployeddifficult to guess the 4-tuple (the source and onedestination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Note: Both [SITW] and [DTASA] provide charts which can give the most often used reliable endreader an idea as to end protocols for data communication. Yet whenthe time it was defined over 20 years agotakes to penetrate an unprotected system. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the internet, as we know it, was4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a different place lacking manyRST, SYN or DATA segment into a TCP connection by carefly crafting the sequence number of the threats that are now common. Recently several rather serious threats have been detailed thatspoofed segment to be in the current receive window. This can pose new methods for both denial of service andcause the connection to either abort or possibly cause data injection by blind attackers.corruption. This document details those threats and alsoproposes somesmall changesmodifications to the way TCP handles inbound segments that either eliminatecan reduce the threats or at least minimize them to a more acceptable level.probability of such an attack. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Blind reset4 1.1. The RESET attack using the RST bit. . . . . . . . . . . . . 5 2.1 Description of the attack. . . . . . . . 4 1.2. Attack probabilities . . . . . . . . . . . . . . . . . . . 5 2.2 Solution2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 58 3. Blind reset attack using the SYNRST bit . . . . . . . . . . . . . 7 3.19 3.1. Description of the attack . . . . . . . . . . . . . . . . 7 3.2 Solution .9 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 79 4. Blind data injectionreset attack using the SYN bit . . . . . . . . . . . . . 11 4.1. Description of the attack . . . . 9 4.1. . . . . . . . . . . . . 11 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 5.1. Description of the attack . . . . . . . . . . . . . . . . 9 4.2 Solution13 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13 6. ACK throttling . . . 9 5.. . . . . . . . . . . . . . . . . . . . . 15 7. Backward Compatibility and Other considerations . . . . . . . 11 6.16 8. Middlebox considerations . . . . . . . . . . . . . . . . . . . 13 6.117 8.1. Middlebox that cacheresend RST's . . . . . . . . . . . . . . . . 13 6.217 8.2. Middleboxes that advance sequence numbers . . . . . . . . 13 7.17 9. Interoperability Testing . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9.24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.125 14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.225 14.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17. 26 Intellectual Property and Copyright Statements . . . . . . . . 18. . 27 1. Introduction TCP (RFC793 )[RFC0793] is widely deployed and one ofthe most often usedcommon reliable end to end protocolstransport protocol used for data communication.communication in todays Internet. Yet when it was defined over 20 years ago the internet,Internet, as we know it, was a different place lacking many of the threats that are now common. Recently several rather serious threats have been detailedTCP spoofing attacks are one such attack that can pose new methods for both denial of service and possibly data injectionare seen on the Internet today. In a TCP spoofing attack, an off-path attacker crafts TCP packets by blind attackers. This document details those threatsforging the IP source and also proposes some small changes todestination addresses as well as the way TCP handles inbound segmentssource and destination ports (commonly referred to as a 4-tuple value) so that either eliminate the threats or at least minimize them toa more acceptable level. Most of these proposals modify handling procedures for DATA, RST and SYN's as definedtarget TCP endpoint can associate such a packet with an existing TCP connection. Note that in RFC793  but doand of itself guessing this 4-tuple value is not cause interoperability issues. The authors feelalways easy for an attacker. But there are some applications (e.g. BGP [RFC1771]) that manymay have a tendency to use the same set(s) of ports on either endpoint making the odds of guessing correctly the changes proposed4-tuple value much easier. When an attacker is successful in this document would, if TCP were being standardized today,guessing the 4-tuple value, one of three types of injection attacks may be requiredwaged against a long-lived connection. RST - Where an attacker injects a reset segment hoping to cause the connection to be intorn down. SYN - Where an attacker injects a 'SYN' hoping to cause the base TCP documentreceiver to believe the peer has restarted and so tear down the lack of these procedures is moreconnection state. DATA - Where an artifact ofattacker tries to inject a "DATA" segment to corrupt the time when TCP was developed than any strict requirementcontents of the protocol. For some uses of TCP, an alternative protection againsttransmission. 1.1. The RESET attack Focusing upon the threats that these changes address has already been implemented and deployedRESET attack, let's examine this attack in more detail to get an overview as to how it works and how this document proposes addressing the TCP MD5 Signature Option (RFC2385 ). Becauseissue. For this option is not negotiated andattack the goal is implemented with a manually established shared key or password, it has been used for protecting usesto cause one of TCP in whichthe two endpoints are managed, such as for BGP peers. RFC3562  provides importance guidance for users of RFC2385  for decreasing their vulnerability to key-guessing. Yet another commonly known mitigation technique is cryptography, especially IPSec. For IPSec to work, both endsof the connection need to agree on the propertiesto use forincorrectly tear down the connection and also agree upon a pre-shared key. Instate, effectively closing the absence of PKI infrastructure,connection. To do this may be inconvenient. IPSec with manual keys can be used to avoid using ISAKMP. However, this adds considerable burden onthe administration of such solution. If ISAKMP wereattacker needs to be used, this would typically require all firewalls in the path betweenhave or guess several pieces of information (namely): 1) The 4-tuple value containing the two TCP endpoints to allow UDP traffic for at least ISAKMP to function. Further, IPSecIP address and NAT have long been known to have interoperability issues.TCP implementations SHOULD also introduce ephemeralport randomization. By randomizing ephemeral portsnumber of both ends of the connection. For one side (usually the server) guessing the port number is a trivial exercise. The client side may or may not be easy for an attacker would haveto guess depending on a less easy timenumber of factors most notably the operating system and application involved. 2) A sequence number that will be used in guessingthe four tuples neededRST. This sequence number will be a starting point for a series of guesses to mountattempt to present a successful attack. Since ephemeral ports are 16 bit values andRST segment to a connection endpoint that would be acceptable to it. Any random value may be used to guess the initial sequence number. 3) The window size that the two endpoints are using. This value does NOT have to be the exact window size since a subsetsmaller value used in lieu of the entire available port numbers, it iscorrect one will just cause the attacker to generate more segments before succeeding in his mischieve. Most modern operating systems have a weaker defense than an exact sequence number match as proposed heredefault window size which usually is a 32- bit value and changes dramatically withinapplied to most connections. Some applications however may change the window size to better suit the lifeneeds of the application. So often times the attacker, with a connection. Nevertheless, bothfair degree of them are complimentary solutionscertainty (knowing the application that will make it difficultis under attack), can come up with a very close approximation as to launch attacks discussed below. Alternative proposals, includingthe actual window size in use on the connection. After assembling the above set of cookies (or, use ofinformation the timestamp option asattacker begins sending spoofed TCP segments with the RST bit set and a cookie) requireguessed TCP sequence number. Each time a new RST segment is sent, the sequence number guess is incremented by the window size. Without mitigation [SITW] has shown that such an attack is much easier to accomplish then previously assumed. This is because RFC793 [RFC0793] specifies that any RST within the current window is acceptable. A slight modification to the TCP state machine can be made which makes such an attack much more difficult to accomplish. If the receiver examines the incoming RST segment and validates that the sequence number exactly matches the sequence number that is next expected, then such an attack becomes much more difficult then outlined in [SITW] (i.e. the attacker would have to generate 1/2 the entire sequence space, on average). This document will discuss the exact details of what needs to be changed within TCP's state machine to mitigate all three types of attacks (RST, SYN and DATA). 1.2. Attack probabilities Every application has control of a number of factors that effect drastically the probability of a successful spoofing attack. These factors include such things as: Window Size - Normally settable by the application but often times defaulting to 32,768 or 65,535 depending upon the operating system (Medina05 [Medina05]). Server Port number - This value is normally a fixed value so that a client will know where to connect to the peer at. Thus this value normally provides no additional protection. Client Port number - This value may be a random ephemeral value, if so, this makes a spoofing attack more difficult. There are some clients, however, that for whatever reason either pick a fixed client port or have a very guessable one (due to the range of ephemeral ports available with their operating system or other application considerations) for such applications a spoofing attack becomes less difficult. For the purposes of the rest of this discussion we will assume that the attacker knows the 4-tuple values. This assumption will help us focus on the effects of the window size verses the number of TCP packets an attacker must generate. This assumption will rarely be true in the real Internet since at least the client port number will provide us with some amount of randomness (depending on operating system). To successfully inject a spoofed packet (RST, SYN or DATA), in the past, the entire sequence space (i.e. 2^32) was often considered available to make such an attack unlikely. [SITW] demonstrated that this assumption was incorrect and that instead of [1/2 X 2^32] packets (assuming a random distribution) [1/2 X (2^32/window)] packets is required. Placing real numbers on this formula we see that for a window size of 32,768, an average of 65,536 packets would need to be transmitted in order to "spoof" a TCP segment that would be acceptable to a TCP receiver. A window size of 65,535 reduces this even further to 32,768 packets. With rises in bandwidth to both peersthe home and office, it can only be expected that the values for default window sizes will continue to implementrise in order to better take advantage of the changes before anynewly available bandwidth. As we can see from the above discussion this weakness lowers the bar quite considerably for likely attacks. But there is one additional protectiondependency which is the duration of the TCP connection. A TCP connection that lasts only a few brief packets, as often is the case for web traffic, would not be subject to such an attack since the connection may not be established long enough for an attacker to generate enough traffic. However there is a set of applications such as BGP [RFC1771] which is judged to be potentially most affected by this vulnerability. BGP relies on a persistent TCP session between BGP peers. Resetting the connection can result in medium term unavailability due to the need to rebuild routing tables and route flapping see [NISCC] for further details. It should be noted that there are existing alternative protection against the threats that this document addresses. For further details regarding the attacks and the existing techniques, please refer to draft [DTASA] 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. TCP terminology should be realized. 2.interpreted as described in RFC793 [RFC0793]. 3. Blind reset attack using the RST bit 2.13.1. Description of the attack It has been traditionally thought that for a blind attacker to reset a TCP connection the attacker would have to guess a single sequence numberAs described in the TCP sequence space. This would in effect requireintroduction, it is possible for an attacker to generate (2^^32) segments in order to reseta connection. Recent papers have shown this to not necessarily"RST" segment that would be the case. An attacker need only guessacceptable to a number that lies between the lastTCP receiver by guessing a "in-window" sequence number acknowledged andnumbers. In particulary RFC 793, p37, states the lastfollowing: "In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number acknowledged added tois in the receiver window (RCV.WND). Modern operating systems normally defaultwindow. In the RCV.WND to about 32,768 bytes. This means that a blind attacker need only guess 65,535SYN-SENT state (a RST segments (2^^32/RCV.WND)received in orderresponse to reset a connection. At DSL speeds this means that most connections (assumingan initial SYN), the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). WithRST is acceptable if the rise of broadband availability and increasing available bandwidth, many Operating Systems have raised their default RCV.WND to as much as 64k, thus making these attacks even easier. 2.2 SolutionACK field acknowledges the SYN." 3.2. Mitigation RFC793 [RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows: 1) If the RST bit is set and the sequence number is outside the expected window,current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND) , silently drop the segment. 2) If the RST bit is set and the sequence number is acceptable i.e.: (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then reset the connection. Instead, this document proposes the following changes should be made to provide someprotection against such an attack. A) If the RST bit is set and the sequence number is outside the expectedcurrent receive window, silently drop the segment. B) If the RST bit is set and the sequence number exactly matches the next expected sequence number, reset the connection. C)number (RCV.NXT), then TCP MUST reset the connection. C) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the current receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST send an acknowledgment (challenge ACK): <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> After sending the challenge ACK, TCP MUST drop the unacceptable segment and stop processing the incoming packet further. The previous text,quoted from RFC793 pg 37 would thus become: In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number exactly matches the next expected sequence number. If the the RST bit is setarrives and theits sequence number field does not exactlyNOT match the next expected sequence value, yetnumber but is within the acceptable window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND) send an acknowledgment: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> After sending the acknowledgment, dropwindow, then the unacceptable segment and return. This solution forms a challenge/response with any RSTreceiver should generate an ACK. In all other cases where the valueSEQ-field does not exactlymatch the expected valueand yetis outside the window, the receiver MUST silently discard the segment. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is withinacceptable if the window.ACK field acknowledges the SYN. In all other cases of a legitimate reset withoutthe exact sequence number,receiver MUST silently discard the consequences of this new challenge/ response will be thatsegment. With the peer requires an extra round trip time beforeabove slight change to the connection can be reset.TCP state machine, it becomes much harder for an attacker to generate an acceptable reset segment. In ordercases where the remote peer did generate a RST but it fails to alleviate multiple RSTs/SYNs from triggering multiplemeet the above criteria (the RST sequence number was within the window but NOT the exact expected sequence number) when the challenge ACKs, aACK throttling mechanism SHOULD be implemented. Suggested values areis sent back, it will no longer have the transmission control block (TCB) related to this connection and hence as per RFC793 [RFC0793], the remote peer will send no more than 10 challenge ACKs ina 5second window. These values MUST be tunable to accommodate different requirements. ACK throttling if implemented successfully can lead to several advantages. Besides preventingRST back. The sequence number of the second RST is derived from the RST/ACK war outlined inacknowledgment number of the section below,incoming ACK. This second RST if it can also alleviate spurious fast retransmits atreaches the remote end caused by flood of duplicate ACKs and also save spurious processing requiredsender will cause the connection to sendbe aborted since the sequence number would now be an ACK onexact match. Note that the victim side. 3.above mitigation may cause a non-amplification ACK exchange. This concern is detailed in 4. Blind reset attack using the SYN bit 3.14.1. Description of the attack Analysis of the reset attack, which usesattack using the RST flagbit, highlights another possible avenue for a blind attacker.attacker using a similar set of sequence number guessing. Instead of using the RST bit an attacker can use the SYN bit as wellwith the exact same symantics to tear down a connection. Using the same guessing technique, repeated SYN's can be generated with sequence numbers incrementing by an amount not larger than the window size apart and thus eventually cause the connection to be terminated. 3.2 Solution4.2. Mitigation RFC793 [RFC0793] currently requires handling of a segment with the SYN bit set in the synchronized state to be as follows: 1) If the SYN bit is set and the sequence number is outside the expected window, send an ACK back to the sender. 2) If the SYN bit is set and the sequence number is acceptable i.e.: (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to the sender. Instead, changing the handling of the SYN in the synchronized state to the following will provide complete protection frommitigate this attack: 1)A) If the SYN bit is set, irrespective of the sequence number, TCP MUST send an ACK (also referred to as challenge ACK) to the remote peer: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> After sending the acknowledgment, TCP MUST drop the unacceptable segment and return. This solution again forms a challenge response with the peer as in the previous section.stop processing further. By alwayssending an ACK toACK, the sender, a challenge/responseremote end sender is setup withchallenged to confirm the peer.loss of the previous connection and the request to start a new connection. A legitimate peer, after restart, would not have a TCB in the synchronized state. Thus when the ACK arrives the peer should send a RST segment back with the sequence number derived from the ACK field that caused the RST. Note, there is one corner case forThis RST will confirm that the remote TCP endpoint has indeed closed the previous connection. Upon receipt of a valid RST, the local TCP endpoint MUST terminate its connection. The local TCP endpoint should then rely on SYN attack problemretransmission from the remote end to re- establish the connection. A spoofed SYN, on the other hand, will then have generated an additional ACK which the peer will discarded as a duplicate ACK and will not affect the established connection. Note that this mitigation does leave one corner case un-handled which will prevent the successfulreset of the connection. Thisa connection when it should be reset (i.e. it is a result ofnon spoofed SYN wherein a peer really did restart). This problem occurs when the RFC793  specificationrestarting host chooses the exact same IP address and is nothingport number that it was using prior to do withits restart. By chance the proposed solution. In this problem, if a restartingrestarted host generates a SYN withmust also choose an initial sequence number that isof exactly equal to RCV.NXT(RCV.NXT - 11) of the remote TCP endpoint that is still in the established state and if the SYN arrives atstate. Such a case would cause the peer that is still holdingreceiver to generate a "challenge" ack as described above. But since the stale connection, anACK willwould be generated. Thiswithin the outgoing connections window the inbound ACK will have an ack value of RCV.NXTwould be acceptable, and the sender of the SYN will be acceptable todo nothing with the restarting host whichresponse ACK. This sequence will acceptcontinue as the ACK and do nothing. TheSYN will then be retransmittedsender continually times out and retransmits the SYN until such time as the behavior will repeat. This could lead to an initialization failure. Subsequentconnection attempts will hopefully succeed by choosingattempt fails. This corner case is a new ISN thatresult of the RFC793 [RFC0793] specification and is not equal to RCV.NXT - 1. A similar problem will be seen shouldintroduced by the SYN contain data. 4.proposed mitigations. Note that the above mitigation may cause a non-amplification ACK exchange. This concern is detailed in Section 10 5. Blind data injection attack 4.15.1. Description of the attack A third type of attack is also highlighted by both the RST and SYN attacks. It is quitealso possible to inject data into a TCP connection by simply guessing the a sequence value that isnumber within the window.current receive window of the victim. The ACK value of any data segment is considered valid as long as it does not acknowledge data ahead of the next segment to send. In other words an ACK value is acceptable if it is (SND.UNA-(2^^31-1))(SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). This means that an attacker simply needhas to guess two ACK values with every guessed sequence number so that the chances ofsuccessfully injecting data into a connection are 1 in ((2^^32((2^32 / RCV.WND) * 2). When an attacker successfully injects data into a connection the data will sit in the receiver's re-assembly queue until the peer sends enough data to bridge the gap between the RCV.NXT value and the injected data. At that point one of two things will occur either: a) An ACKpacket war will ensue with the receiver indicating that it has received data up until RCV.NXT (which includes the attackers data) and the sender sending a correctivean ACK with a valuean acknowledgment number less than RCV.NXT (the real sequence number of the last byte sent).RCV.NXT. b) The sender will send enough data to the peer which will move RCV.NXT even further along past the injected data. In either case the injected data will be made readable toDepending upon the upper layer andTCP implementation in question and the TCP traffic characteristics at that time, data corruption may result. In case <a>(a) the connection will eventually be reset by one of the sides.sides unless the sender produces more data that will transform the ACK war into case (b). The reset will usually occur via User Time Out (UTO) (see section 18.104.22.168 of [RFC1122]). Note that the protections illustrated in this section neither cause an ACK war nor prevent one from occurring if data is actually injected into a connection. The ACK war is a natural consequence of any data injection that is successful. 4.2 Solutiona product of the attack itself and cannot be prevented (other than by preventing the data from being injected). 5.2. Mitigation An additional input check should be added to any incoming segment. The ACK value shouldMUST be acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). MAX.SND.WND is defined as the largest window that the local receiver has ever advertised to it'sits peer. This window is themay be a scaled value i.e. the value may be larger than 65,535 bytes.bytes (RFC1323 [RFC1323]). This small check will greatly reduce the vulnerability ofto an attacker guessing a valid sequence number since not only must he/she guess the sequence number in window, but must also guess a proper ACK value within a scoped range. This solutionmitigation reduces but does not eliminate the ability to generate false segments. It does however reduce the probability that invalid data will be injected to a more acceptable level. For those applicationsinjected. Note that wish to close this attack completely RFC2385  should be deployed betweenthe two endpoints. 5. Backward Compatibility and Other considerations 1) The proposed solutionabove mitigation may cause a non-amplification ACK exchange. This concern is backward compatible as it uses the semantics laid downdetailed in RFC793  to defend against it's own weakness. Referring6. ACK throttling In order to the figure below, if we assume that the RST (1.c) was in flight when thealleviate multiple RSTs/SYNs from triggering multiple challenge ACKs, an ACK (2) left TCP A, TCP B hasthrottling mechanism SHOULD be implemented. Suggested values are to send no way of knowing what triggered the ACK. For all it cares, the ACK might have been a result of the data or the RST that it had sent earlier. Hencemore than 10 challenge ACKs in either case, TCP B must reply to this ACK with an appropriate RST that isa 5 second window. These numbers are empirical in keeping with RFC793 . 2) Concernsnature and have been raised thatobtained from the challenge responseRST throttling mechanism will lead toimplemented in some OS's. These value MUST be tunable by a reflector kind of attack. In this attack, it is believedsystem administrator to accommodate different preceived threats. An alternative mechanism may also be used that does not involve an attacker with higher bandwidth can potentially spoof SYN or RST packets within the window and cause ACK flooding toadditional timer. In such an implementation a remote peersender would only send X acks between any window advancment. Note that may havesuch a lower bandwidth. These concerns are misplaced because it is triviallimitation will not require a timer but must be implemented with care to causeavoid a victimdeadlock in the face of ack loss. An implementation SHOULD include a ACK throttling mechanism to generate an ACK. A spoofer can simply send packets with sequence numbersbe conservative. Currently there is no known bad behavior that are outsidecan be attributed to the acceptable windowlack of the attacker or send anACK that acknowledgesthrottling, but as a general principle, if ever invoked, something thatincorrect is not yet sent. Further, an attacker can also simply generate data packetsoccuring and such a mechanisn will act as a failsafe that fall withinprotects both the window to cause ansender and the network. An administrator who is more concerned about protecting his bandwidth and CPU utilization may set smaller ACK to be sent. RFC793  also mandates thatthottling values whereas an ACK be sent if the incoming SYNadministrator who is more interested in faster cleanup of stale connections (i.e. concerned about excess TCP state) may decide to set a higher value thus allowing more RST's to an established connection falls outside the acceptable window. All these scenarios canbe usedprocessed in any given time period. The time limit SHOULD be tunable to launchhelp timeout brute force attacks faster than a flood attack. However, thepotential harmlegitimate flood of such attacks are lowRSTs. 7. Backward Compatibility and can be easily detected due to the volumeOther considerations 1) All of packets generated. The latter is a strong deterrent to such attacks. 3)the proposed mitigation techniques in this document are totally compatible with existing (RFC793 [RFC0793]) compliant TCP implementations as this document introduces no new assumptions or conditions. 2) There is a corner scenario in the above proposed solutionsmitigations which will require more than one round trip time to successfully abort the connection as per the figure below. This scenario is similar to the one in which the original RST was lost in the network. TCP A TCP B 1.a. ESTABLISHEDESTAB <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTABLISHEDESTAB b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTABLISHEDESTAB c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED 2. ESTABLISHEDESTAB --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED (ACK for 1.a) ... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED 3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED (for 1.c) ... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE 4.a. ESTABLISHEDESTAB <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A b. ESTABLISHEDESTAB --> <SEQ=101><ACK=500><CTL=ACK> c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED 5. RESPONSE arrives at A, but isdropped because of being outsince its outside of window. 6. ESTABLISHEDESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A 7. CLOSED CLOSE 4)CLOSED 3) For the solutionmitigation to be totallymaximally effective against the vulnerabilities discussed in this document, both ends of the TCP connection need to have the fix. Although, having itthe mitagations at one end might prevent that end from being exposed to the attack, the connection is still vulnerable at the other end. 6.8. Middlebox considerations The following scenarios were brought to notice by the tcpm working group members as middlebox issues which may cause the proposed solution to behave in an unexpected manner. 6.18.1. Middlebox that cacheresend RST's Consider a middlebox BM-B tracking connection between two TCP endhosts AE-A and C.E-C. If CE-C sends a RST with a sequence number that is within the window but not an exact match to reset the connection and if BM-B does not have the fix proposed here, it willmay clear the connection and ask A to doforward the same.RST to E-A saving an incorrect sequence number. If AE-A does not have the fix it will clear the connection and everything will be fine. However if AE-A does have the proposed fix above, it will send a challenge ACK. BACK to E-C. M-B, being a middlebox willmiddlebox, may intercept this ACK and resend the RST cached earlier that was responsible for bringing down the connection. However,on behalf of E-C with the RSTold sequence number. This RST, will again beagain, not acceptable and willmay trigger a challenge ACK again.ACK. This willmay cause a RST/ACK war to happen. However,occur. However we believe that if such a case exists in the Internet the middle box design itself is flawed. Consider a similar scenario where the RST from M-B to E-A gets lost, E-A will continue to hold the connection and E-A might send an ACK an arbitrary time later after the connection state was destroyed at M-B. For this case, M-B will have to cache the RST for an arbitrary amount of time till until it is confirmed that the connection has been cleared at E-A. Further, this is not compliant to RFC793 which dictates that the sequence number of a RST has to be derived from the acknowledgment number of the incoming ACK segment. 8.2. Middleboxes that advance sequence numbers Some middleboxes may compute RST sequence numbers at the higher end of the acceptable window. The scenario is the same as the earlier case, but in this case instead of sending the cached RST, the middlebox (M-B) sends a RST that computes its sequence number as a sum of the ack field in the ACK and the window advertised by the ACK that was sent by E-A to challenge the RST as depicted below. The difference in the sequence numbers between step 1 and 2 below is due to data lost in the network. TCP A Middlebox 1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED 2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED Although the authors are not aware of middleboxesan implementation that actually do this and believedoes the design itself is flawed in that givenabove, it could be mitigated by implementing the scenario thatACK throttling mechanism described earlier. 9. Interoperability Testing Interoperability testing was performed among the RSToperating systems from B toJuniper Networks, WindRiver Systems, QNX Software and Cisco Systems. The following topology was used: +---------+ +---------+ |TCP A got lost on|----+------|Victim B | +---------+ | +---------+ | +---------+ | |Attacker |----+ +---------+ In the way, A will continue to holdabove topology B is the connection andunit under test. TCP A might send an ACKis a remote peer and the attacker workstation is used to generate malicious spoofed packets. First, an arbitrary time afterunmodifed stack had the following tests performed upon it. A TCP connection was brought down atup between TCP endpoint A and B. In this case, B will have to cache the RST for an arbitrary amountThe 4-tuple of time till it's confirmed thatthe connection has been cleared at A. 6.2 Middleboxes that advance sequence numbers Some Middleboxes may compute RST sequence numbers atwas manually populated in the higher end ofbrute force attack script running on the acceptable window.attacker workstation. The setup isscript crafted TCP packets by using the same as4-tuple and by generating sequence numbers that incremented from 0 to the earlier case, butmax permissible sequence number (2^32 -1) in this case insteadvarying increments of sendingwindow size of 8K to 64K (the window size agreed by A and B was larger than 8K, but was ignored to make the cached RST,test conservative). The time it took to cause the middlebox sendsconnection to reset/corrupt was then recorded. The test was repeated by then generating sequence numbers that were window (the one agreed between endpoints A and B) size apart. It was observed that increasing the window size caused the connection to be reset faster than with a RSTsmaller window. Further, it was also observed that computes it'sthe initial sequence number as(ISN) selection also played a sumrole in how fast a connection was aborted, with ISN selection in the lower half of the ack fieldsequence space aborting sooner than an ISN in the ACKupper half. Results were also found to be influenced by any active data transfer on the connection. Active data transfer sometimes caused the connection to be reset faster and some other times to slow the attack. The window advertised bysize selection at the ACK that was sent by Aattacker workstation and how it compares to challengethe RST as depicted below.actual window size between A and B was also found to be a factor. The difference intests were repeated with a stack that did have the sequence numbers between step 1fix and 2 below is dueas expected it became difficult as compared to data lost inthe network. TCPprevious results to cause the connection to abort. [Editors Note: Add time test data gathered at inter-op here!!] 10. Security Considerations A Middlebox 1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED 2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED Althoughreflector attack is possible with the authors are not aware ofproposed RST/SYN mitigation techniques. Here an off-path attacker can cause a working implementationvictim to send an ACK segment for each spoofed RST/SYN segment that lies within the current receive window of the victim. This, however, does not cause any sort of amplification since the above, it could be mitigated by implementingattacker must generate a segment for each one that the RST throttling mechanism described earlier. 7.victim will generate. 11. IANA Considerations This document contains no IANA considerations. 12. Contributors Mitesh Dalal and Amol Khare of Cisco Systems came up with the solution for the RST/SYN attacks. Anantha Ramaiah and Randall Stewart of Cisco Systems discovered the data injection vulnerability and together with Patrick Mahan and Peter Lei of Cisco Systems found solutions for the same. Paul Goyette, Mark Baushke, Frank Kastenholz, Art Stine and David Wang of Juniper Networks provided the insight that apart from RSTs, SYNs could also result in formidable attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of Wind River Systems and Xiaodan Tang of QNX Software along with the folks above helped in ratifying and testing the interoperability of the suggested solutions. 8.13. Acknowledgments Special thanks to Sharad Ahlawat,Mark Allman, Ted Faber, Steve Bellovin, Vern Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong and the tcpm WG members for suggestions and comments. 9.Some of the text in this document has been derived from 14. References 9.114.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.  Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option",[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2385, August 1998. 9.22119, March 1997. 14.2. Informative References [DTASA] Touch, J., "Defending TCP Against Spoofing Attacks", draft-touch-tcp-antispoof-00 (work in progress), July 2004. [Medina05] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps (figure 6)". [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - Vulnerability Issues in TCP". [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. [SITW] Watson, P., ""Slipping"Slipping in the Window: TCP Reset attacks"". Author's Addressattacks". Authors' Addresses Randall R. Stewart Editor 4875 Forest Drive Suite 200 Columbia, SC 29206 USA Phone: Email: email@example.com Mitesh Dalal Editor 170 Tasman Drive San Jose, CA 95134 USA Phone: +1-408-853-5257 Email: firstname.lastname@example.org Intellectual Property Statement 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 email@example.com. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005).(2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.