TCP

我们现在所说的 TCP 协议通常是指 1981 年 9 月 发表的 RFC 793 和一系列后续 RFC 定义的协议，其主体定义距今已经超过 40 年了（当然如果细究下去的话，第一份正式的文档是 RFC 675，而 RFC 793 本身也是针对一年前的 RFC 761 的修正，不过大部分实现者使用的基础依然是 RFC 793）。

今天在邮件列表里看到 John Nagle （就是发明 TCP Nagle 算法的 那个 John Nagle）提到希望 OpenSSL 提供一些帮助自动检测中间人攻击的 方法。简单地说，因为中间人攻击会改变双方看到的加密流（密钥变了），因此，如果上层协议包含了加密流的某些特征，攻击者想要实施中间人攻击的成本就会大大增加。他同时举了一个例子，一种早期的加密电话会在话机上显示从密文开始的部分计算的两位数字，而通话双方则通过通话来确认数字相同，这样，中间人攻击的实施者就必须解析语音并替换掉相关的字词来避免被发现。

简单的例子是，比如准备发出 HTML/XML 之前，首先发出它们在加密之后的密文的 hash。攻击者如果简单地截获并重新加密文档，则攻击会被立即发现；如果缓冲并重新计算结果，必然会引入延迟；如果事先准备好文件并做好计算，则需要在看到文件之前就准备好这些资料（不过实际应用中，攻击者很可能会选择这么做）。这些都会增加实施中间人攻击的困难。

之前一直没什么概念，今天看了微软的 KB 321169 的解释，大致如此：

• 客户端 (SMB Redirector) 如果启用了 security signature，则必须等待命令处理完成才会发出下一条SMB；
• 服务器端如果启用了延迟ACK，则可能需要过200ms (Windows 2000)才会给出ACK回应

不过感觉这个解释依然不是很有说服力—-文档上说，SMB服务器端是需要对 NT_TRANSACT_NOTIFY_CHANGE 给出回应的，那么这种情况下ACK不就回应回来了吗？或者说，只要收到了 ACK 就说明服务器端已经处理了这条 SMB？哪位帮忙理解一下？

最近看到一个很有意思的攻击。记一笔。

针对 SYN Flood 攻击（特点是攻击者发出大量 SYN 请求，但并不完成 TCP 握手），目前操作系统会采用 SYNcookie 予以反制。FreeBSD上的实现是在系统资源充足的时候采用标准的握手机制，而当发现存在可能的攻击（即可用的 TCP 状态资源不足时）应用 SYNcookie；SYNcookie是将TCP状态建立推迟到三次握手 之后，具体做法是将服务器本地的一个秘密数据与来源/目的IP、端口编码来形成序号来发出SYN+ACK，并在收到对方回应ACK时验证这个序号的真实性。

因为我用的网卡多数都是em(4)，所以在最近的升级中也就利用了它提供的TSO功能。TSO是一项减少服务器负载的技术，其原理是将TCP相关的一部分计算交给网卡去做。

今天把用于 FreeBSD 7-CURRENT的RFC 3522实现发到邮件列表之后，Mike告诉我，爱立信对Eifel Detection算法拥有专利，并禁止非开源产品无偿使用此专利。

还在老地方。RFC 3522 (Eifel Detection)是一项用于避免TCP中不必要的重传的技术。

关于FreeBSD近期希望完成的网络协议栈方面改进，请参见 Wiki。

今天 陈总 去机房把NetGear换成了一台Cisco的29系列产品。但愿能把捣乱的人抓住……

除了这个之外，也试试看Cisco对我做的一些TCP协议变动是否支持良好。

今天有人在IETF的tcpm上有人提到一篇《Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse》的论文。看起来是一个很有意思的问题，即，乐观ACK(opt-ack)在作者看来是一个潜在的DoS攻击工具，而且粗略地扫了一眼，这个问题很可能是真实存在的（但是这篇2005年11月的文章，目前似乎只有Sun做了回应……)，等周末有时间研究一下。

很有问题。

今天尝试backport了一下TCP/IP的buffer space autosize，貌似编译过去了，顺手修了一个6.2的问题，也许是那位同学没注意跟6-STABLE的diff就直接commit了？