6.1.5 重传的 TCP 数据包

6.1.5 重传的 TCP 数据包

本文档规定, ECN-capable TCP 实现 MUST NOT 在重传数据包的 IP 头部中设置任一 ECT codepoint (ECT(0) 或 ECT(1)), 并且 TCP 数据接收端应忽略到达但位于接收端当前窗口之外的数据包上的 ECN 字段. 这是为了提高对拒绝服务攻击的防护, 并提高对随后在网络中被丢弃的数据包上的 ECN 拥塞指示的稳健性.

首先, 我们注意到, 如果 TCP 发送端在重传数据包上设置 ECT codepoint, 则如果一个不必要重传的数据包随后在网络中被丢弃, 端节点将永远不会收到来自路由器设置 CE codepoint 的拥塞指示. 因此, 在重传数据包上设置 ECT codepoint 将与拥塞指示的可靠交付不兼容, 即使对随后在网络中被丢弃的数据包也是如此.

此外, 能够伪造 TCP 发送端 IP 源地址的攻击者可以发送具有任意序列号且 IP 头部中设置了 CE codepoint 的数据包. 收到这种伪造数据包时, TCP 数据接收端会确定该数据不在当前接收窗口内, 并返回重复确认. 我们将 TCP 数据接收端处的 out-of-window packet 定义为数据位于接收端当前窗口之外的数据包. 收到 out-of-window packet 时, TCP 数据接收端必须决定是否把数据包头部中的 CE codepoint 视为有效拥塞指示, 因而决定是否向 TCP 数据发送端返回 ECN-Echo 指示. 如果 TCP 数据接收端忽略 out-of-window packet 中的 CE codepoint, 则 TCP 数据发送端将不会收到这一潜在合法的网络拥塞指示, 从而违反端到端拥塞控制. 另一方面, 如果 TCP 数据接收端采信 out-of-window packet 中的 CE 指示并向 TCP 数据发送端报告拥塞指示, 则创建伪造 out-of-window packet 的恶意节点就成功 "attacking" 了 TCP 连接, 迫使数据发送端不必要地降低 (减半) 其拥塞窗口. 为防止这种拒绝服务攻击, 我们规定合法的 TCP 数据发送端 MUST NOT 在重传数据包上设置 ECT codepoint, 并且 TCP 数据接收端应忽略 out-of-window packet 上的 CE codepoint.

不在重传数据包上设置 ECT(0) 或 ECT(1) 的一个缺点是, 它拒绝向重传数据包提供 ECN 保护. 然而, 对处于轻度拥塞且完全 ECN-capable 环境中的 ECN-capable TCP 连接而言, 因拥塞而丢弃数据包的场合应很少, 因而出现重传数据包的实例也应很少. 如果数据包正在被重传, 则已经存在 ECN 无法防止的数据包丢失 (来自损坏或拥塞).

我们注意到, 如果路由器为 TCP 连接内的 ECN-capable 数据包设置 CE codepoint, 则该 TCP 连接保证会收到该拥塞指示, 或在同一数据窗口内收到某种其他拥塞指示, 即使该数据包在网络中被丢弃或重排序也是如此. 我们考虑两种情况: 数据包随后被重传, 以及数据包随后未被重传.

第一种情况中, 如果该数据包被丢弃或延迟, 并且在某个时刻由数据发送端重传, 则该重传是该数据包或同一数据窗口中某个先前数据包发生 Fast Retransmit 或 Retransmit Timeout 的结果. 在这种情况下, 因为数据发送端已经重传了该数据包, 我们知道数据发送端已经对与原始数据包同一数据窗口内某个数据包的拥塞指示作出了响应. 因此, 该数据包的第一次传输设置了 CE codepoint 并随后在网络中被丢弃或延迟, 从而被数据接收端作为 out-of-window packet 忽略, 这一点并不重要, 因为发送端已经对该数据窗口的拥塞指示作出响应.

第二种情况中, 如果该数据包从未由数据发送端重传, 则该数据包是数据接收端收到的该数据的唯一副本, 因而无论它被延迟或重排序了多久, 它都是作为 in-window packet 到达数据接收端. 在这种情况下, 如果该数据包在网络中设置了 CE codepoint, 数据接收端会把它视为有效拥塞指示.