要約

  • SYN Cookieは、復元可能な仮のTCP状態をサーバーのSYN-ACK初期シーケンス番号へ符号化し、3通目のACKが戻るまで明示的なSYN-RECEIVEDレコードを作らない。
  • 戻った値が示すのは、特定の4タプルに対する最近の返信経路へ誰かがアクセスしたことだ。人の本人確認でも、善意の証明でも、アプリケーション容量の予約でもない。
  • 32ビットの領域には情報上限がある。発動条件、復元できるオプション、損失時の挙動、残る資源制約は、実際に動くカーネルとフロントエンドで確認しなければならない。

通常のパッシブオープンでは、サーバーが先に信用を差し出す。SYNを受けるとSYN-RECEIVEDへ進み、SYN-ACKを作り、最後のACKを識別するための情報を半開キューへ残す。相手はまだ、名乗った送信元で返答を受け取れると示していない。それでもサーバー側の有限な状態は使われる。

SYN floodは、この先払いを大量に作る。完了しない開始要求が再送とタイムアウトを待ち、未完了接続の枠を埋める。正規の利用者は、リンクやアプリケーション、確立済み接続に余力があっても入れなくなる。RFC 4987が扱う古典的な対象は接続確立状態であり、すべての帯域や処理資源が同時に尽きたという意味ではない。

対策ごとに、失われるものが違う。backlogを広げれば待てるが、攻撃にさらすメモリも増える。タイマーを短くすれば早く回収できる一方、遅延や損失の大きい正規経路を切りやすい。古い項目の再利用は、正当性ではなく年齢で犠牲を選ぶ。SYN cacheは小さな記録だけを持つ。プロキシは別の装置で握手を終え、費用と意味の境界を移す。

SYN Cookieは記録そのものを持たない。サーバーは、未完了の交換を圧縮した情報とローカル秘密に基づく検査値を、自分の初期シーケンス番号へ入れる。歴史的な構成では、送受信アドレスとポート、クライアントの初期番号、ゆっくり進む時刻カウンター、MSSの区分、サーバー秘密などを組み合わせる。RFC 4987は単一の必須アルゴリズムではなく、複数の実装とトレードオフを記録している。

クライアントは符号化を知る必要がない。通常どおりSYN-ACKを受け取り、サーバーの番号に1を加えたACKを返す。サーバーはその値を戻し、まだ有効な時刻候補を調べ、観測した4タプルで秘密関数を再計算する。一致すれば状態を再構成してESTABLISHEDへ進む。不一致なら、存在しない半開レコードを探さず捨てられる。

これは身分証ではなく、申込者に預けた受領証である。サーバーは自分だけが検証できる札を発行し、台帳を開かない。札が返れば、その宛先の最近のSYN-ACKを誰かが受信、観測、または取得したと分かる。その証拠はローカルなメモリ割り当てには足りても、人名、所属、意図、将来の処理費用までは示さない。

秘密は経路外からの推測を難しくするが、TCPを暗号学的な本人確認へ変えない。経路上の観測者は交換を見られる。実在する送信元を持つボットは正しいCookieを返せる。接続後には、TLS、ソケット、ワーカー、データベース、業務上の割当を消費できる。仕組みが遅らせるのは一つの支出時点であり、支出そのものではない。

記憶を手放す代わりに、情報を圧縮する必要がある。初期シーケンス番号は32ビットで、TCP本来の役割も残る。通常の要求レコードなら最初のSYNにあった全オプションを覚えられる。基本的なCookieでは、鮮度、検査、必須パラメータに同じ空間を分ける。古い方式は、よく使うMSS値への小さな索引だけを持つことがあった。符号化も推定もできない情報は、3通目で復元できない。

Window Scaleは、その損失が性能契約に届く例だ。RFC 7323ではSYN付きセグメントだけで交換し、接続開始時に各方向の倍率を固定する。クライアントの提示値を忘れ、Cookieの拡張でも取り戻せなければ、ACK後に交渉し直すことはできない。RFC 4987は基本方式におけるWindow ScaleやSACKの制約を記し、同時にFreeBSDがTimestampで返送されるビットを使って追加状態を回収した方式も紹介した。

したがって、「SYN Cookieなら常に同じオプションを失う」も、「新しい実装なら全て残る」も誤りだ。確認対象は、運用中のカーネル、バージョン、NIC offload、ロードバランサー、プロキシ、リスナーである。一般文書は検証すべき場所を教えるが、結果の代わりにはならない。

3通目のACKが失われる場合、サーバー先行型のアプリケーションは別の違いを見せる。RFC 4987はSMTPを例に挙げる。クライアントはACKを送り、接続が終わったと思って挨拶を待つ。そのACKが消えると、ステートレスなサーバーには再送判断の元になる記録がなく、アプリケーションにもまだ知らせていない。回復は後続の再送と実装に依存する。メモリを守ることで、沈黙を先に認識する側が変わる。

恒久的にCookieだけを使うより、通常モードと組み合わせる方が境界を保ちやすい。平常時は通常のキューやSYN cacheで豊かな交渉状態と再送動作を残す。リスナーの閾値を超えたときだけCookieへ退避し、既存要求の追い出しを避ける。入口、出口、副作用を測れる緊急割当ポリシーとして扱うべきである。

Linuxの現行文書もtcp_syncookiesを、ソケットのSYN backlogがあふれたときのフォールバックとして説明する。正規の接続率を処理できないサーバーの能力不足を隠すために使ってはならないとも警告する。tcp_max_syn_backlogは、各リスナーが記憶するSYN_RECV要求数を別に扱う。平常需要で常時フォールバックするなら、容量、待ち行列、再送、サービス処理を調べるべきだ。

完全なCookieでも、SYNの受信と解析、秘密計算、SYN-ACK送信、ACK検査は残る。回線、割り込み、キュー、CPUは飽和する。成立後のaccept queue、確立済みソケット、暗号処理、ワーカー、下流依存も有限だ。防御がボトルネックを後段へ移すこと自体は設計どおりでも、後段が見えないなら運用として失敗する。

送信元アドレス検証は別の境界を守る。BCP 38とBCP 84は、ネットワークが偽装送信元を外へ出しにくくし、架空の宛先へ応答させる力を減らす。しかし、実在するホストや正規のピークは握手を完了できる。上流はどの送信元主張を輸出するか決め、エンドポイントはいつ状態を使うか決める。片方で他方を代替できない。

観測では、消した表の代わりに出来事を数える必要がある。RFC 4898は、未成熟キュー、完全な資源割当、アプリケーション受け入れを分け、SYN Cookieでは符号化されたSYN-RCVDが明示レコードとして存在しないと述べる。半開数がゼロでも、負荷がゼロとは限らない。単にサーバーが記憶をやめただけかもしれない。

SYN受信、SYN-ACK、再送、backlog占有とあふれ、Cookie発行、有効・無効・期限切れの返却、成立、accept queue、アプリ受け入れを一つの連鎖として見るべきだ。通常時とCookie成立時のMSS、Window Scale、SACK、Timestamp、ECN、Fast Openも比較する。モード切替の記録がなければ、状態と一緒に証拠まで消える。

TCP Fast Openは、別のCookieとリプレイ前提の下でSYNにアプリケーションデータを載せる。RFC 7413は、従来型SYN Cookieのフォールバックがそのデータや意味を保持すると保証しない。フロントエンド、負荷分散、offload、カーネルを同じ経路で試す必要がある。同じCookieという語は、同じ契約を意味しない。

SCTPは、遅延状態のための器を最初から用意した対照例である。RFC 9260の4段階セットアップは、関連付けに必要な情報を持つ可変長State Cookieを運び、MAC、時刻、寿命で守る。TCPとの互換性も、コンパクトなSYN Cookieとの同一性もない。ただし、進化する交渉を既存の番号へ詰め込むより、明示的な器の方が意味を保ちやすいことを示す。

共通仕様は握手の不変条件と既知の代償を記述できる。しかし、個々のリスナーのメモリ、遅延、必須オプション、後段コストまでは決められない。Heng Luの最小初期仕様は発動と損失の判断を実行者へ残す。Running-Code Primacyが最後の判定を与える。設定値は意図にすぎず、実際の接続がどの状態と利用者を維持したかが現実である。

出典