SYN cookies
このサーバ側の関数はクライアントからは知ることができない。
この方法で計算されたシーケンス番号は、サーバ側の t を含んだ一方向ハッシュ関数で計算された値を含んでいるため、クライアントが勝手に偽装することはできない (クライアントはハッシュを計算するための秘密の初期値を探索せねばならず、しかもこの値は時間によって変化するので値を大量に収集し記憶しても約 1分後には使えなくなってしまう)。また、この番号は TCP の MSS値に関する情報を含んでいるので、クライアントが正しく ACKパケットを返してきた際には、サーバはたとえ元のクライアントの MSS 要求値を覚えていなくても、それに近い値を利用することができる (ただし、MSS 以外の TCP 関連のオプションはすべて無視されてしまう)。さらに、ここで t は 64秒間のあいだ不変であるので、t の変わらない間に返されてきた ACK パケットのシーケンス番号であれば、(クライアントとサーバが同じ t を共有しているため) サーバはシーケンス番号を正しくチェックできる。こうしてサーバが記憶領域を割り当てなくても、安全な TCP 接続が可能になる。
SYN flood 攻撃の問題点は、TCP 接続が開始する前からサーバがクライアントの SYN パケットによって記憶領域を消費してしまう点にあった。通常この記憶領域には、クライアント側のIPアドレスとポート番号、接続に使うシーケンス番号、およびクライアントが指定してきた TCP接続に関する様々な設定 (TCPウィンドウの大きさなど) が格納される。また、サーバは SYN パケットを受けとった後、クライアントに対して SYN ACK パケットを返す。ここにはその TCP 接続に関連づけられたTCPシーケンス番号が含まれている。TCPシーケンス番号はこれ以降の TCP通信の中で、クライアントおよびサーバが共通して使用する。そのためクライアントはサーバが返した SYN ACK パケットにあるシーケンス番号を ACK パケットの中に含めてくるはずである。この性質を利用して、もしサーバが本来メモリ上に記憶するべき情報を返りの SYN ACK パケットの中のシーケンス番号の中に埋めこむことができれば、サーバ側は SYN を受けとった直後に記憶領域を消費する必要はなくなり、ACK パケットが来てからはじめて TCP 接続用の領域を割り当てればよくなる。大量の SYN flood を行うほとんどの攻撃元ホストは IP アドレスを偽装しているため、このシーケンス番号を受けとることはできず、したがってサーバに正しい ACK パケットを送ることができない。その結果、サーバは正当なホストからの接続要求のみに対応 (メモリ割り当て) することができる。このアイデアを進めたものが SYN cookies である。