博士

やあ、ロボ子。今日はSYN-ACKパケットについて話すのじゃ。

ロボ子

SYN-ACKパケットですか、博士。どのような内容なのでしょうか？

博士

SYN-ACKパケットは通常44バイトじゃ。でも攻撃者はTCPオプションを使って、このサイズを大きくできるのじゃ。

ロボ子

TCPオプションでサイズを大きくする、ですか？具体的にはどのように？

博士

例えば、MSS、TS、SAckOK、WScale、TFO cookieなどを使うのじゃ。これらを有効に使うだけで、最小のSYNパケットより約62%も多くの帯域幅を消費させられるのじゃぞ！

ロボ子

62%もですか！それはすごいですね。元の要約に「72バイト対44バイト」とありますね。

博士

そうじゃ。でもヘッダーがあると増幅率は下がるのじゃ。MSSオプションを省略すると、増幅を維持できるのじゃ。

ロボ子

なるほど。他にSYN-ACKに関連する攻撃はありますか？

博士

TCP Fast Open (TFO) とSYN-ACK攻撃じゃな。TFO cookieを使うと、SYN-ACKの応答を大きくできるのじゃ（SYN-ACKあたり12バイト追加）。

ロボ子

TFO cookieで12バイト追加、ですか。でも、最初のSYN-ACKパケット以降はどうなるのでしょう？

博士

TFOを有効にしたホストは、最初のSYN-ACKパケット以降の追加のSYN-ACKパケットに12バイトのヘッダーオプションを含めないのじゃ。最初のSYN-ACKは72バイトじゃが、その後の再送信試行は60バイトになるのじゃ。

ロボ子

最初のSYN-ACKだけ大きいんですね。SYN-ACKリフレクション攻撃への対策はあるのでしょうか？

博士

それが難しいところじゃ。SYN-ACKリフレクションの軽減は困難で、やりすぎると実際のクライアントやTCPセッションに悪影響を及ぼす可能性があるのじゃ。

ロボ子

悪影響、ですか。具体的には？

博士

接続性の問題、パフォーマンスの低下、正当なホスト/ユーザーのブロックにつながる可能性があるのじゃ。

ロボ子

それは困りますね。根本的な解決策はあるのでしょうか？

博士

IETFとネットワーク事業者が連携して、スプーフィングされたトラフィックのルーティングを特定・防止することじゃ。IETFはBCP38を公開していて、ネットワーク事業者がスプーフィングされたトラフィックのルーティングを防止する方法を概説しているのじゃ。

ロボ子

なるほど。ネットワーク事業者側の対策が重要なのですね。

博士

そういうことじゃ。しかし、根本的な解決には時間がかかるじゃろうな。

ロボ子

そうですね。博士、今日はありがとうございました。

博士

どういたしまして。ところでロボ子、SYN-ACKパケットって、なんだかお菓子の名前みたいじゃない？『シン・アック』味のポテトチップスとか…

ロボ子

博士、それはちょっと…（苦笑）。