以前写过一篇“TCP SYN-Cookie背后的人和事”，今天讨论一下发现我的理解也没有到位。看来工程中没有看过code或者调试过，对于一个事物就无法透彻的理解。本来的理解是SynCookie不会保存Session信息，取而代之的是要保存一个32bits的Cookie。一个依据就是：如果本机没有保存任何秘密，如何验证正常的Session呢？如果不用秘密攻击者就可以制造出对应的第三个ACK，可以等待一段时间发送第三个ACK造成实际的攻击。
现在有了更多的理解，看起来SynCookie不用本地缓存任何内容，包括不会生成的32bits的cookie。
Wiki之中介绍了Syn Cookiehttp://en.wikipedia.org/wiki/SYN_cookies：
Sync-Cookie的使用是有前提的，仅仅适用于伪造IP地址的连接建立请求，对于基于正常的连接建立的DDos攻击不起作用。对于伪造原始IP，攻击者无法知道box产生的S2C的ISN，这个就是最基本的Secret，即使没有SynCookie的存在，第三个伪造报文也无法构造成功。剩余的需求就是SynCookie如何根据正常连接的第三个报文验证ACK报文并且构建Session了。
Syn-Cookie feature的前提有以下几个：
要完成的事情是在第三个报文到来之后做以下两件事：
SynCookie通过精心构造Syn-Ack中的ISN来实现上述功能：
let t = A slowly incrementing timestamp (typically time() logically right-shifted 6 positions, which gives a 64 second resolution)
let m = The maximum segment size (MSS) value that the server would have stored in the SYN queue entry
let s = The result of a cryptographic secret function computed over the server IP address and port number, the client IP address and port number, and the value t. The returned value s must be a 24-bit value.
The initial TCP sequence number, i.e. the SYN cookie, is computed as follows:
首先，验证ACK报文是否属于先前的Session
1.将ACK的Seq-1得到原始的ISN。验证t字段同当前的系统time比较，表明是否收到的内容超时，例如30秒才收到ACK。
2.是否m字段和本地MSS比较有效，m值应该是一个index，本地保存8个固定的M值，否则无法回复连接的MSS字段。
3.计算s，看看是否相等，这里的t是box产生的，也应该算是secret了。
然后，是Session的恢复
1.five-tuple自然可以从报文中读取
2.Sequence Number从报文直接读取就可以了
3.MSS的恢复
这里面必须要有的字段是m，也就是需要重建MSS，因为头两个报文都没有缓存，因此MSS无法恢复，SynCookie这里应该使用全局仅有的8个MSS。
4.其他TCP Options
没办法恢复，这个在Wiki之中提到了，属于limitation。
对于这个算法有如下思考：
1.只有m字段这里是必须的，其他的属于锦上添花。
2.对于s的计算使用全局的key就可以了，不用每个SYN不同。
Syn看似和SynProxy不同实际有类似之处，SynCookie实际上伪造了S2C的Sequence Number，对于后继的traffic和Proxy一样都要对于报文的Sequence Number进行重写。
这回看起更清楚的理解了这个功能