doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc5961.txt b/doc/rfc/rfc5961.txt
new file mode 100644
index 0000000..69170d7
--- /dev/null
+++ b/doc/rfc/rfc5961.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        A. Ramaiah
+Request for Comments: 5961                                         Cisco
+Category: Standards Track                                     R. Stewart
+ISSN: 2070-1721                                                   Huawei
+                                                                M. Dalal
+                                                                   Cisco
+                                                             August 2010
+
+
+         Improving TCP's Robustness to Blind In-Window Attacks
+
+Abstract
+
+   TCP has historically been considered to be protected against spoofed
+   off-path packet injection attacks by relying on the fact that it is
+   difficult to guess the 4-tuple (the source and destination 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 longer-term connections (e.g., H-323 or
+   Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP
+   implementations more vulnerable to these types of spoofed packet
+   injection attacks.
+
+   Many of these long-term TCP applications tend to have predictable IP
+   addresses and ports that makes it far easier for the 4-tuple (4-tuple
+   is the same as the socket pair mentioned in RFC 793) to be guessed.
+   Having guessed the 4-tuple correctly, an attacker can inject a TCP
+   segment with the RST bit set, the SYN bit set or data into a TCP
+   connection by systematically guessing the sequence number of the
+   spoofed segment to be in the current receive window.  This can cause
+   the connection to abort or cause data corruption.  This document
+   specifies small modifications to the way TCP handles inbound segments
+   that can reduce the chances of a successful attack.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5961.
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 1]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Applicability Statement ....................................3
+      1.2. Basic Attack Methodology ...................................4
+      1.3. Attack probabilities .......................................5
+   2. Terminology .....................................................7
+   3. Blind Reset Attack Using the RST Bit ............................7
+      3.1. Description of the Attack ..................................7
+      3.2. Mitigation .................................................7
+   4. Blind Reset Attack Using the SYN Bit ............................9
+      4.1. Description of the Attack ..................................9
+      4.2. Mitigation .................................................9
+   5. Blind Data Injection Attack ....................................10
+      5.1. Description of the Attack .................................10
+      5.2. Mitigation ................................................11
+   6. Suggested Mitigation Strengths .................................12
+   7. ACK Throttling .................................................12
+   8. Backward Compatibility and Other Considerations ................13
+   9. Middlebox Considerations .......................................14
+      9.1. Middlebox That Resend RSTs ................................14
+      9.2. Middleboxes That Advance Sequence Numbers .................15
+      9.3. Middleboxes That Drop the Challenge ACK ...................15
+   10. Security Considerations .......................................16
+   11. Contributors ..................................................17
+   12. Acknowledgments ...............................................17
+   13. References ....................................................17
+      13.1. Normative References .....................................17
+      13.2. Informative References ...................................17
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 2]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+1.  Introduction
+
+   TCP [RFC0793] is widely deployed and the most common reliable end-to-
+   end transport protocol used for data communication in today's
+   Internet.  Yet, when it was standardized over 20 years ago, the
+   Internet was a different place, lacking many of the threats that are
+   now common.  The off-path TCP spoofing attacks, which are seen in the
+   Internet today, fall into this category.
+
+   In a TCP spoofing attack, an off-path attacker crafts TCP packets by
+   forging the IP source and destination addresses as well as the source
+   and destination ports (referred to as a 4-tuple value in this
+   document).  The targeted TCP endpoint will then associate such a
+   packet with an existing TCP connection.  It needs to be noted that,
+   guessing this 4-tuple value is not always easy for an attacker.  But
+   there are some applications (e.g., BGP [RFC4271]) that have a
+   tendency to use the same set(s) of ports on either endpoint, making
+   the odds of correctly guessing the 4-tuple value much easier.  When
+   an attacker is successful in guessing the 4-tuple value, one of three
+   types of injection attacks may be waged against a long-lived
+   connection.
+   RST -  Where an attacker injects a RST segment hoping to cause the
+      connection to be torn down.  "RST segment" here refers to a TCP
+      segment with the RST bit set.
+   SYN -  Where an attacker injects a SYN hoping to cause the receiver
+      to believe the peer has restarted and therefore tear down the
+      connection state.  "SYN segment" here refers to a TCP segment with
+      SYN bit set.
+   DATA -  Where an attacker tries to inject a DATA segment to corrupt
+      the contents of the transmission.  "DATA segment" here refers to
+      any TCP segment containing data.
+
+1.1.  Applicability Statement
+
+   This document talks about some known in-window attacks and suitable
+   defenses against these.  The mitigations suggested in this document
+   SHOULD be implemented in devices that regularly need to maintain TCP
+   connections of the kind most vulnerable to the attacks described in
+   this document.  Examples of such TCP connections are the ones that
+   tend to be long-lived and where the connection endpoints can be
+   determined, in cases where no auxiliary anti-spoofing protection
+   mechanisms like TCP MD5 [RFC2385] can be deployed.  These mitigations
+   MAY be implemented in other cases.
+
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 3]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+1.2.  Basic Attack Methodology
+
+   Focusing upon the RST attack, we examine this attack in more detail
+   to get an overview as to how it works and how this document addresses
+   the issue.  For this attack, the goal is for the attacker to cause
+   one of the two endpoints of the connection to incorrectly tear down
+   the connection state, effectively aborting the connection.  One of
+   the important things to note is that for the attack to succeed the
+   RST needs to be in the valid receive window.  It also needs to be
+   emphasized that the receive window is independent of the current
+   congestion window of the TCP connection.  The attacker would try to
+   forge many RST segments to try to cover the space of possible windows
+   by putting out a packet in each potential window.  To do this, the
+   attacker needs to have or guess several pieces of information namely:
+
+   1) The 4-tuple value containing the IP address and TCP port number 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 to guess depending on a
+      number of factors, most notably the operating system and
+      application involved.
+
+   2) A sequence number that will be used in the RST.  This sequence
+      number will be a starting point for a series of guesses to attempt
+      to present a RST segment to a connection endpoint that would be
+      acceptable to it.  Any random value may be used to guess the
+      starting 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 smaller value used in
+      lieu of the correct one will just cause the attacker to generate
+      more segments before succeeding in his mischief.  Most modern
+      operating systems have a default window size that usually is
+      applied to most connections.  Some applications however may change
+      the window size to better suit the needs of the application.  So
+      often times the attacker, with a fair degree of certainty (knowing
+      the application that is under attack), can come up with a very
+      close approximation as to the actual window size in use on the
+      connection.
+
+   After assembling the above set of information, the attacker begins
+   sending spoofed TCP segments with the RST bit set and a guessed TCP
+   sequence number.  Each time a new RST segment is sent, the sequence
+   number guess is incremented by the window size.  The feasibility of
+   this methodology (without mitigations) was first shown in [SITW].
+   This is because [RFC0793] specifies that any RST within the current
+   window is acceptable.  Also, [RFC4953] talks about the probability of
+   a successful attack with varying window sizes and bandwidth.
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 4]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   A slight enhancement to TCP's segment processing rules 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 than
+   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 segment
+   processing rules to mitigate all three types of attacks (RST, SYN,
+   and DATA).
+
+1.3.  Attack probabilities
+
+   Every application has control of a number of factors that drastically
+   affect 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
+      (see Figure 6 of [Medina05]).
+
+   Server Port number  - This value is normally a fixed value so that a
+      client will know where to connect to the peer.  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 versus 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 the 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 * 2^32)
+   packets (assuming a random distribution), (1/2 * (2^32/window))
+
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 5]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   packets are required.  In other words, the mean number of tries
+   needed to inject a RST segment is (2^31/window) rather than the 2^31
+   assumed before.
+
+   Substituting numbers into 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.  At today's access bandwidths, an attack of that size
+   is feasible.
+
+   With rises in bandwidth to both the home and office, it can only be
+   expected that the values for default window sizes will continue to
+   rise in order to better take advantage of the newly available
+   bandwidth.  It also needs to be noted that this attack can be
+   performed in a distributed fashion in order potentially gain access
+   to more bandwidth.
+
+   As we can see from the above discussion this weakness lowers the bar
+   quite considerably for likely attacks.  But there is one additional
+   dependency that 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 [RFC4271], that 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 term-
+   medium unavailability due to the need to rebuild routing tables and
+   route flapping; see [NISCC] for further details.
+
+   For applications that can use the TCP MD5 option [RFC2385], such as
+   BGP, that option makes the attacks described in this specification
+   effectively impossible.  However, some applications or
+   implementations may find that option expensive to implement.
+
+   There are alternative protections against the threats that this
+   document addresses.  For further details regarding the attacks and
+   the existing techniques, please refer to [RFC4953].  It also needs to
+   be emphasized that, as suggested in [TSVWG-PORT] and [RFC1948], port
+   randomization and initial sequence number (ISN) randomization would
+   help improve the robustness of the TCP connection against off-path
+   attacks.
+
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 6]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+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].  TCP
+   terminology should be interpreted as described in [RFC0793].
+
+3.  Blind Reset Attack Using the RST Bit
+
+3.1.  Description of the Attack
+
+   As described in the introduction, it is possible for an attacker to
+   generate a RST segment that would be acceptable to a TCP receiver by
+   guessing in-window sequence numbers.  In particular [RFC0793], page
+   37, states the following:
+
+      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 is in the window.  In the
+      SYN-SENT state (a RST received in response to an initial SYN), the
+      RST is acceptable if the ACK field acknowledges the SYN.
+
+3.2.  Mitigation
+
+   [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
+      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, implementations SHOULD implement the following steps in
+   place of those specified in [RFC0793] (as listed above).
+
+   1) If the RST bit is set and the sequence number is outside the
+      current receive window, silently drop the segment.
+
+   2) If the RST bit is set and the sequence number exactly matches the
+      next expected sequence number (RCV.NXT), then TCP MUST reset the
+      connection.
+
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 7]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   3) 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.  Further
+      segments destined to this connection will be processed as normal.
+
+   The modified RST segment processing 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 RST arrives and its sequence number field does NOT
+   match the next expected sequence number but is within the window,
+   then the receiver should generate an ACK.  In all other cases, where
+   the SEQ-field does not match and is 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 acceptable if the ACK field acknowledges the SYN.  In all
+   other cases the receiver MUST silently discard the segment.
+
+   With the above slight change to the TCP state machine, it becomes
+   much harder for an attacker to generate an acceptable reset segment.
+
+   In cases where the remote peer did generate a RST, but it fails to
+   meet the above criteria (the RST sequence number was within the
+   window but NOT the exact expected sequence number), when the
+   challenge ACK is sent back, it will no longer have the transmission
+   control block (TCB) related to this connection and hence as per
+   [RFC0793], the remote peer will send a second RST back.  The sequence
+   number of the second RST is derived from the acknowledgment number of
+   the incoming ACK.  This second RST, if it reaches the sender, will
+   cause the connection to be aborted since the sequence number would
+   now be an exact match.
+
+   A valid RST received out of order would still generate a challenge
+   ACK in response.  If this RST happens to be a genuine one, the other
+   end would send an RST with an exact sequence number match that would
+   cause the connection to be dropped.
+
+   Note that the above mitigation may cause a non-amplification ACK
+   exchange.  This concern is discussed in Section 10.
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 8]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+4.  Blind Reset Attack Using the SYN Bit
+
+4.1.  Description of the Attack
+
+   The analysis of the reset attack using the RST bit highlights another
+   possible avenue for a blind attacker using a similar set of sequence
+   number guessing.  Instead of using the RST bit, an attacker can use
+   the SYN bit with the exact same semantics to tear down a connection.
+
+4.2.  Mitigation
+
+   [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, the handling of the SYN in the synchronized state SHOULD be
+   performed as follows:
+
+   1) 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 stop processing further.
+
+   By sending an ACK, the remote peer is challenged to confirm the 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.
+
+   This RST will confirm that the remote peer 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 retransmission from the remote end to
+   re-establish the connection.
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                    [Page 9]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   A spoofed SYN, on the other hand, will then have generated an
+   additional ACK that the peer will discard 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 reset of a connection when it should be reset
+   (i.e., it is a non-spoofed SYN wherein a peer really did restart).
+   This problem occurs when the restarting host chooses the exact same
+   IP address and port number that it was using prior to its restart.
+   By chance, the restarted host must also choose an initial sequence
+   number of exactly (RCV.NXT - 1) of the remote peer that is still in
+   the established state.  Such a case would cause the receiver to
+   generate a "challenge" ACK as described above.  But since the ACK
+   would be within the outgoing connections window, the inbound ACK
+   would be acceptable, and the sender of the SYN will do nothing with
+   the response ACK.  This sequence will continue as the SYN sender
+   continually times out and retransmits the SYN until such time as the
+   connection attempt fails.
+
+   This corner case is a result of the [RFC0793] specification and is
+   not introduced by these new requirements.
+
+   Note that the above mitigation may cause a non-amplification ACK
+   exchange.  This concern is discussed in Section 10.
+
+5.  Blind Data Injection Attack
+
+5.1.  Description of the Attack
+
+   A third type of attack is also highlighted by both the RST and SYN
+   attacks.  It is also possible to inject data into a TCP connection by
+   simply guessing a sequence number within the 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)) <= SEG.ACK <= SND.NXT).  The (2^31 - 1) in the
+   above inequality takes into account the fact that comparisons on TCP
+   sequence and acknowledgment numbers is done using the modulo 32-bit
+   arithmetic to accommodate the number wraparound.  This means that an
+   attacker has to guess two ACK values with every guessed sequence
+   number so that the chances of successfully injecting data into a
+   connection are 1 in ( 1/2 (2^32 / RCV.WND) * 2).  Thus, the mean
+   number of tries needed to inject data successfully is
+   1/2 (2*2^32/RWND) = 2^32/RCV.WND.
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 10]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   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:
+
+   1) A packet war will ensue with the receiver indicating that it has
+      received data up until RCV.NXT (which includes the attacker's
+      data) and the sender sending an ACK with an acknowledgment number
+      less than RCV.NXT.
+
+   2) The sender will send enough data to the peer that will move
+      RCV.NXT even further along past the injected data.
+
+   Depending upon the TCP implementation in question and the TCP traffic
+   characteristics at that time, data corruption may result.  In case
+   (a), the connection will eventually be reset by one of the 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 4.2.3.5 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 product of the attack
+   itself and cannot be prevented (other than by preventing the data
+   from being injected).
+
+5.2.  Mitigation
+
+   All TCP stacks MAY implement the following mitigation.  TCP stacks
+   that implement this mitigation MUST add an additional input check to
+   any incoming segment.  The ACK value is considered acceptable only if
+   it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
+   SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
+   above condition MUST be discarded and an ACK sent back.  It needs to
+   be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
+   duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
+   acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
+   ACK, drop the segment, and return".  The "ignored" above implies that
+   the processing of the incoming data segment continues, which means
+   the ACK value is treated as acceptable.  This mitigation makes the
+   ACK check more stringent since any ACK < SND.UNA wouldn't be
+   accepted, instead only ACKs that are in the range ((SND.UNA -
+   MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
+
+   A new state variable MAX.SND.WND is defined as the largest window
+   that the local sender has ever received from its peer.  This window
+   may be scaled to a value larger than 65,535 bytes ([RFC1323]).  This
+   small check will reduce the vulnerability to an attacker guessing a
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 11]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   valid sequence number, since, not only one must guess the in-window
+   sequence number, but also guess a proper ACK value within a scoped
+   range.  This mitigation reduces, but does not eliminate, the ability
+   to generate false segments.  It does however reduce the probability
+   that invalid data will be injected.
+
+   Implementations can also chose to hard code the MAX.SND.WND value to
+   the maximum permissible window size, i.e., 65535 in the absence of
+   window scaling.  In the presence of the window scaling option, the
+   value becomes (MAX.SND.WND << Snd.Wind.Scale).
+
+   This mitigation also helps in improving robustness on accepting
+   spoofed FIN segments (FIN attacks).  Among other things, this
+   mitigation requires that the attacker also needs to get the
+   acknowledgment number to fall in the range mentioned above in order
+   to successfully spoof a FIN segment leading to the closure of the
+   connection.  Thus, this mitigation greatly improves the robustness to
+   spoofed FIN segments.
+
+   Note that the above mitigation may cause a non-amplification ACK
+   exchange.  This concern is discussed in Section 10.
+
+6.  Suggested Mitigation Strengths
+
+   As described in the above sections, recommendation levels for RST,
+   SYN, and DATA are tagged as SHOULD, SHOULD, and MAY, respectively.
+   The reason that DATA mitigation is tagged as MAY, even though it
+   increased the TCP robustness in general is because, the DATA
+   injection is perceived to be more difficult (twice as unlikely) when
+   compared to RST and SYN counterparts.  However, it needs to be noted
+   that all the suggested mitigations improve TCP's robustness in
+   general and hence the choice of implementing some or all mitigations
+   recommended in the document is purely left to the implementer.
+
+7.  ACK Throttling
+
+   In order to alleviate multiple RSTs/SYNs from triggering multiple
+   challenge ACKs, an ACK throttling mechanism is suggested as follows:
+
+   1) The system administrator can configure the number of challenge
+      ACKs that can be sent out in a given interval.  For example, in
+      any 5 second window, no more than 10 challenge ACKs should be
+      sent.
+
+   2) The values for both the time and number of ACKs SHOULD be tunable
+      by the system administrator to accommodate different perceived
+      levels of threat and/or system resources.
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 12]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   It should be noted that these numbers are empirical in nature and
+   have been obtained from the RST throttling mechanisms existing in
+   some implementations.  Also, note that no timer is needed to
+   implement the above mechanism, instead a timestamp and a counter can
+   be used.
+
+   An implementation SHOULD include an ACK throttling mechanism to be
+   conservative.  While we have not encountered a case where the lack of
+   ACK throttling can be exploited, as a fail-safe mechanism we
+   recommend its use.  An implementation may take an excessive number of
+   invocations of the throttling mechanism as an indication that network
+   conditions are unusual or hostile.
+
+   An administrator who is more concerned about protecting his bandwidth
+   and CPU utilization may set smaller ACK throttling values whereas an
+   administrator 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 be processed in any
+   given time period.
+
+   The time limit SHOULD be tunable to help timeout brute force attacks
+   faster than a potential legitimate flood of RSTs.
+
+8.  Backward Compatibility and Other Considerations
+
+   All of the new required mitigation techniques in this document are
+   totally compatible with existing ([RFC0793]) compliant TCP
+   implementations as this document introduces no new assumptions or
+   conditions.
+
+   There is a corner scenario in the above mitigations that 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 13]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+          TCP A                                                 TCP B
+   1.a. ESTAB        <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <--  ESTAB
+     b. (delayed)    ... <SEQ=400><ACK=101><CTL=ACK><DATA> <--  ESTAB
+     c. (in flight)  ... <SEQ=500><ACK=101><CTL=RST>       <--  CLOSED
+   2.   ESTAB        --> <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. ESTAB        <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
+     b. ESTAB        --> <SEQ=101><ACK=500><CTL=ACK>
+     c. (in flight)  ... <SEQ=500><ACK=0><CTL=RST>         <--  CLOSED
+   5.   RESPONSE arrives at A, but dropped since its outside of window.
+   6.   ESTAB        <-- <SEQ=500><ACK=0><CTL=RST>         4.c reaches A
+   7.   CLOSED                                                   CLOSED
+
+   For the mitigation to be maximally effective against the
+   vulnerabilities discussed in this document, both ends of the TCP
+   connection need to have the fix.  Although, having the mitigations at
+   one end might prevent that end from being exposed to the attack, the
+   connection is still vulnerable at the other end.
+
+9.  Middlebox Considerations
+
+9.1.  Middlebox That Resend RSTs
+
+   Consider a middlebox M-B tracking connections between two TCP end
+   hosts E-A and E-C.  If E-C sends a RST with a sequence number that is
+   within the window but not an exact match to reset the connection and
+   M-B does not have the fix recommended in this document, it may clear
+   the connection and forward the RST to E-A saving an incorrect
+   sequence number.  If E-A does not have the fix, the connection would
+   get cleared as required.  However, if E-A does have the required fix,
+   it will send a challenge ACK to E-C.  M-B, being a middlebox, may
+   intercept this ACK and resend the RST on behalf of E-C with the old
+   sequence number.  This RST will, again, not be acceptable and may
+   trigger a challenge ACK.
+
+   The above situation may result in a RST/ACK war.  However, we believe
+   that if such a case exists in the Internet, the middlebox is
+   generating packets a conformant TCP endpoint would not generate.
+   [RFC0793] dictates that the sequence number of a RST has to be
+   derived from the acknowledgment number of the incoming ACK segment.
+   It is outside the scope of this document to suggest mitigations to
+   the ill-behaved middleboxes.
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 14]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   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 until it is confirmed that the connection has been cleared at
+   E-A.
+
+9.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 the
+   sum of the acknowledgment 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 an implementation that does the
+   above, it could be mitigated by implementing the ACK throttling
+   mechanism described earlier.
+
+9.3.  Middleboxes That Drop the Challenge ACK
+
+   It also needs to be noted that, some middleboxes (Firewalls/NATs)
+   that don't have the fix recommended in the document, may drop the
+   challenge ACK.  This can happen because, the original RST segment
+   that was in window had already cleared the flow state pertaining to
+   the TCP connection in the middlebox.  In such cases, the end hosts
+   that have implemented the RST mitigation described in this document,
+   will have the TCP connection left open.  This is a corner case and
+   can go away if the middlebox is conformant with the changes proposed
+   in this document.
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 15]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+10.  Security Considerations
+
+   These changes to the TCP state machine do NOT protect an
+   implementation from on-path attacks.  It also needs to be emphasized
+   that while mitigations within this document make it harder for off-
+   path attackers to inject segments, it does NOT make it impossible.
+   The only way to fully protect a TCP connection from both on- and off-
+   path attacks is by using either IPsec Authentication Header (AH)
+   [RFC4302] or IPsec Encapsulating Security Payload (ESP) [RFC4303].
+
+   Implementers also should be aware that the attacks detailed in this
+   specification are not the only attacks available to an off-path
+   attacker and that the counter measures described herein are not a
+   comprehensive defense against such attacks.
+
+   In particular, administrators should be aware that forged ICMP
+   messages provide off-path attackers the opportunity to disrupt
+   connections or degrade service.  Such attacks may be subject to even
+   less scrutiny than the TCP attacks addressed here, especially in
+   stacks not tuned for hostile environments.  It is important to note
+   that some ICMP messages, validated or not, are key to the proper
+   function of TCP.  Those ICMP messages used to properly set the path
+   maximum transmission unit are the most obvious example.  There are a
+   variety of ways to choose which, if any, ICMP messages to trust in
+   the presence of off-path attackers and choosing between them depends
+   on the assumptions and guarantees developers and administrators can
+   make about their network.  This specification does not attempt to do
+   more than note this and related issues.  Unless implementers address
+   spoofed ICMP messages [RFC5927], the mitigations specified in this
+   document may not provide the desired protection level.
+
+   In any case, this RFC details only part of a complete strategy to
+   prevent off-path attackers from disrupting services that use TCP.
+   Administrators and implementers should consider the other attack
+   vectors and determine appropriate mitigations in securing their
+   systems.
+
+   Another notable consideration is that a reflector attack is possible
+   with the required RST/SYN mitigation techniques.  In this attack, an
+   off-path attacker can cause a victim to send an ACK segment for each
+   spoofed RST/SYN segment that lies within the current receive window
+   of the victim.  It should be noted, however, that this does not cause
+   any amplification since the attacker must generate a segment for each
+   one that the victim will generate.
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 16]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+11.  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.
+
+12.  Acknowledgments
+
+   Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern
+   Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong,
+   Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra
+   Murphy, Brian Carpenter, Cullen Jennings, and other members of the
+   tcpm WG for suggestions and comments.  ACK throttling was introduced
+   to this document by combining the suggestions from the tcpm working
+   group.
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
+                 RFC 793, September 1981.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+13.2.  Informative References
+
+   [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>.
+
+   [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.
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 17]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+   [RFC1323]     Jacobson, V., Braden, B., and D. Borman, "TCP
+                 Extensions for High Performance", RFC 1323, May 1992.
+
+   [RFC1948]     Bellovin, S., "Defending Against Sequence Number
+                 Attacks", RFC 1948, May 1996.
+
+   [RFC2385]     Heffernan, A., "Protection of BGP Sessions via the TCP
+                 MD5 Signature Option", RFC 2385, August 1998.
+
+   [RFC4271]     Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+                 Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC4302]     Kent, S., "IP Authentication Header", RFC 4302,
+                 December 2005.
+
+   [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
+                 RFC 4303, December 2005.
+
+   [RFC4953]     Touch, J., "Defending TCP Against Spoofing Attacks",
+                 RFC 4953, July 2007.
+
+   [RFC5927]     Gont, F., "ICMP Attacks against TCP", RFC 5927,
+                 July 2010.
+
+   [SITW]        Watson, P., "Slipping in the Window: TCP Reset
+                 attacks", Presentation at 2004 CanSecWest,
+                 <http://cansecwest.com/csw04archive.html>.
+
+   [TSVWG-PORT]  Larsen, M. and F. Gont, "Transport Protocol Port
+                 Randomization Recommendations", Work in Progress,
+                 August 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 18]
+
+RFC 5961                      TCP Security                   August 2010
+
+
+Authors' Addresses
+
+   Anantha Ramaiah
+   Cisco Systems
+   170 Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   Phone: +1 (408) 525-6486
+   EMail: ananth@cisco.com
+
+
+   Randall R. Stewart
+   Huawei
+   148 Crystal Cove Ct
+   Chapin, SC  29036
+   USA
+
+   Phone: +1 (803) 345-0369
+   EMail: rstewart@huawei.com
+
+
+   Mitesh Dalal
+   Cisco Systems
+   170 Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   Phone: +1 (408) 853-5257
+   EMail: mdalal@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramaiah, et al.              Standards Track                   [Page 19]
+