一、介绍

TCP[RFC0793]是当今Internet上用于数据通信的最常见、最可靠的端到端传输协议。然而，20多年前它标准化时，互联网环境和现在相比有很大区别（缺少许多现在常见的威胁）。如今互联网上常见的off-path TCP欺骗攻击就是这样一种威胁。

在TCP欺骗攻击中，off-path攻击者通过伪造IP源和目标地址以及源和目标端口（称为4元组值）来伪造TCP数据包。然后，目标TCP主机会将这样的数据包当作其已有的某个的TCP连接的数据包进行处理。需要注意的是，猜测这个4元组值对于攻击者来说有时是十分困难的。但是有一些应用程序（例如BGP[RFC4271]）倾向于在连接两端上使用相同的端口集，这使得正确猜测4元组值的几率大大提高。当攻击者成功猜出4元组值时，可能会对长期连接发起三种类型的注入攻击之一：

RST：攻击者通过注入RST段来导致连接中断。”RST段”这里是指RST标志位置位的TCP段。
SYN：攻击者注入SYN段来使得接收方相信连接的另一方已重新启动，从而中断连接状态。”SYN段“指SYN标志位置位的TCP段。
DATA：攻击者试图注入数据段来破坏传输内容。”这里的“数据段”是指任何包含数据的TCP段。

1.1 Applicability Statement

本文讨论了一些已知的in-window攻击以及针对这些攻击的适当防御措施。本文档中建议的缓解措施应在定期需要维护最易受本文档所述攻击影响的TCP连接的设备中实施。这类TCP连接指那些倾向于长期的连接，并且无法部署诸如TCP MD5[RFC2385]之类的辅助反欺骗保护机制。

1.2 Basic Attack Methodology

以RST攻击为例，对于此攻击，攻击者的目标是使连接的两个端点之一错误地中断连接状态，从而有效地中止连接。需要注意的重要事项之一是，要使攻击成功，RST必须位于有效的接收窗口中。还需要强调的是，接收窗口独立于TCP连接的当前拥塞窗口。攻击者会试图伪造许多RST段，通过在每个可能的窗口中放一个数据包来覆盖可能的窗口空间。要做到这一点，攻击者需要掌握或猜测几条信息，即：

包含连接两端的IP地址和TCP端口号的四元组值。对于一方（通常是服务器），猜测端口号很简单。客户端可能很容易被攻击者猜到，也可能不容易被攻击者猜到，这取决于许多因素，尤其是所涉及的操作系统和应用程序。
将在RST段中使用的序列号。此序列号将是一系列猜测的起点，最终实现让连接的另一端接收这个RST段。任何随机值都可以用来猜测起始序列号。
两个端点正在使用的窗口大小。此值不必是确切的窗口大小，因为使用较小的值来代替正确的值只会导致攻击者在成功进行之前测试更多的段。大多数现代操作系统都有一个默认窗口大小，通常应用于大多数连接。但是，有些应用程序可能会更改窗口大小以更好地满足应用程序的需要。通常情况下，攻击者在某型情况（知道受到攻击的应用程序）下，可以得出与连接上使用的实际窗口大小非常接近的近似值。

在获取了上述信息之后，攻击者开始发送RST段（这些段带有猜测性的sequence number）。每次发送一个新的RST段时，序列号猜测值将递增窗口大小。该方法的可行性首次在[SITW]中进行了阐述。这是因为[RFC0793]指定当前窗口中的任何RST都是可接受的。此外，[RFC4953]还讨论了不同窗口大小和带宽的攻击成功的概率。

对TCP的段处理规则稍加改进，就可以对这种攻击进行有效阻断。如果接收方检查传入的RST段并验证序列号是否与下一个预期的序列号完全匹配，那么这时攻击将比[SITW]中概述的要困难得多。本文档将详细讨论TCP的段处理规则中需要更改的内容，以减轻所有三种类型的攻击（RST、SYN和DATA）。

1.3 Attack probabilities

每个应用都有着许多能决定一次欺骗性攻击是否成功的关键元素，这些元素包括：

Window Size：通常由应用程序设定，但是大多数时候默认为32768或65535，这取决于操作系统 (see Figure 6 of [Medina05]).
Server Port number：这个值通常是一个固定的值，因为这样客户端才知道在哪里连接到这个节点。
Client Port number：这个值可能是一个暂时性的随机值，如果是这样的，欺骗性攻击会变难。但有一些客户端会选择一个固定端口号或者很容易猜到的端口号，对这些客户端的攻击就简单了很多。

在后面的介绍中假设攻击者已经获取了四元组。此时我们仅需要关注窗口大小对攻击者必须生成的欺骗性包数量的影响。但是这个假设在实际情况中是不现实的，因为至少客户端的端口号会提供一些随机性（取决于操作系统）

为了为了成功注入一个欺骗性的包（RST、SYN或DATA），在没有进行此强化改动时，攻击者平均需要猜测1/2∗(232/window)1/2 * (2^{32}/window)1/2∗(232/window)次就能成功执行攻击。

利用数字替换上面的公式，这就代表着如果窗口大小为32768，那么攻击者在成功前平均需要猜测65536个包。如果窗口大小为65535，那么包的数量会降低为32768个。在现在的带宽条件下，这种大小的攻击是可行的。并且随着家庭和办公带宽的不断提高，默认窗口大小的值会不断提高，因此可以预见这种攻击带来的威胁会不断提高。

从上述的讨论可以看出这种漏洞带来的隐患。此外还有一个影响因素，这个因素是TCP连接的持续时间，对于网络来说，大多数情况下一个TCP通常只会持续几个包，这种情况并不是这种攻击的目标。然而，还有一些应用，例如BGP [RFC4271]，很容易受到这种vulnerability的影响。BGP依赖于BGP节点间的持续性的TCP。 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.

对于可以使用TCP MD5选项[RFC2385]的应用程序（如BGP），该选项使得本文中描述的攻击实际上不可能发生。但是，一些应用程序或implementation实现该选项的成本很高。

对于本文所述的威胁，还有其他保护措施。有关攻击和现有技术的更多详细信息，请参阅[RFC4953]。还需要强调的是，正如在[TSVWG-PORT]和[RFC1948]中所建议的那样，端口随机化和初始序列号（ISN）随机化将有助于提高TCP连接对路径外攻击的鲁棒性。

三、Blind Reset Attack Using the RST Bit

3.1 对攻击的描述

如同介绍中所述，攻击者可以通过猜测位于有效窗口内的sequence number来生成一个TCP接收方将会接收的RST段。RFC 793中有着如下的陈述：

在所有除了SYN-SENT的状态外，所有的RST段都通过检查SEQ域（sequence number）来进行验证。RST段中的sequence number如果位于接收窗口内，那么它就是有效的。在SYN-SENT状态时（此时的过程是发送初始SYN后接收到了一个RST作为回应），此时这个RST如果ACK域acknowledge了SYN，那么是有效的。

3.2 Mitigation

[RFC0793]对位于synchronized状态的TCP如何处理到来的RST标志位置位的段的规定如下：

如果RST标志位置位并且sequence number在当前接收窗口外 (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND)，那么直接丢弃这个段
如果RST标志位置位并且sequence number可接受，即RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND，那么重置这个连接

本文建议进行对上述进行如下的修改：

如果RST标志位置位并且sequence number在当前接收窗口外，直接丢掉这个段
如果RST标志位置位并且sequence number正好匹配下一个需要的sequence number (RCV.NXT)，这时TCP MUST重置这个连接
如果RST标志位置位并且sequence number并不严格匹配期望接收的sequence number，但是在当前的接收窗口内 (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND)，那么TCP MUST 发送一个acknowledgment信息 (challenge ACK):<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
在发送这个challenge ACK后，TCP MUST丢弃这个不可接受的段，并继续处理将要到达的段。

注意在SYN-SENT状态时（这时会收到一个RST来回应刚发送的SYN），如果这个RST的ACK域acknowledge了这个SYN，那么RST有效。否则接收方MUST丢弃这个段。

在对初始TCP进行上述改动后，对攻击者而言生成一个有效RST段变得困难了许多。

当远端节点的确生成了一个RST，但是没有正好匹配sequence number时，此时challenge ACK被发送回来，但是远端节点已经没有了和这个连接相对应的transmission control block（TCB）。 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.

四、Blind Reset Attack Using the SYN Bit

4.1 对攻击的描述

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 减轻

RFC 793中规定了处于synchronized状态时收到SYN置位的段时进行的处理：

如果SYN标志位置位并且sequence number位于期望窗口外，那么向发送者发送回一个ACK
如果SYN标志位置位并且sequence number是可以接收的，即RCV.NXT≤SEG.SEQ≤RCV.NXT+RCV.WNDRCV.NXT\le SEG.SEQ\le RCV.NXT+RCV.WNDRCV.NXT≤SEG.SEQ≤RCV.NXT+RCV.WND，那么向发送方发送回一个RST段

Instead, the handling of the SYN in the synchronized state SHOULD be performed as follows:

如果SYN标志位置位，那么不考虑sequence number，TCP必须向remote peer发送回一个ACK（也被称为challenge ACK）:<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
在发送了这个acknowledgment后，TCP必须丢弃这个unacceptable segment and stop processing further.

通过发送ACK的机制，remote peer需要验证自己对于先前连接的丢失以及重新启动一个新的连接的请求。一个合法的peer在重启后已经没有了之前处于synchronized状态下的TCB。因此，当ACK到达时，这个peer应当发送回一个RST段，这个段中包含从到达ACK中获取到的sequence number。

这个RST会证实remote peer确实已经关闭了先前的连接。当收到了这个有效的RST后，本地TCP MUST关闭这个自己的连接。本地TCP接下来需要重新经过三次握手来重新建立连接。

一个欺骗性的SYN，
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.