TCP ECE/CWR とは何か – SYN に ECE/CWR が付く理由と ECN の仕組み

TCP のパケットキャプチャで SYN + ECE + CWR が見えることがあります。見慣れない組み合わせなので、異常な TCP フラグ、攻撃っぽい通信、ファイアウォールで落とすべきパケットのように見えるかもしれません。

しかし、多くの場合、SYN + ECE + CWR は異常ではありません。ECN、つまり Explicit Congestion Notification を使えるかどうかを TCP の接続開始時に交渉しているだけです。

この記事では、TCP フラグの ECE と CWR が何を表すのか、SYN に一緒に付く場合と通信中に出る場合で意味がどう違うのか、そしてパケットキャプチャやファイアウォールログで見たときにどう判断すべきかを確認します。

まず結論: SYN の ECE/CWR は ECN の能力交渉

最初に結論から言うと、SYN + ECE + CWR は、通常は ECN の能力交渉として見ます。

ECN は、輻輳をパケットロスだけで知らせるのではなく、IP ヘッダー上の ECN フィールドと TCP ヘッダー上の ECE/CWR を組み合わせて、輻輳を明示的に通知する仕組みです。

ここで注意したいのは、接続開始時の ECE/CWR と、通信中の ECE/CWR は意味が違うことです。

見え方	主な意味	判断
SYN + ECE + CWR	クライアント側が ECN 対応を示す	単体では異常ではない
SYN/ACK + ECE	サーバー側が ECN 対応を返す	ECN 交渉の一部として見る
通信中の ACK に ECE	CE マークされたパケットを受信した通知	経路上の輻輳や AQM の動作を確認する
通信中の CWR	送信側が輻輳ウィンドウを下げた通知	輻輳制御の応答として見る
通信失敗と同時に出る	ミドルボックスが ECN を嫌っている可能性	ファイアウォール、ロードバランサー、NAT、IDS/IPS を確認する

ECE と CWR は ECN のための TCP フラグ

ECE と CWR は、TCP 単体で完結するフラグではありません。ECN では、IP ヘッダー側に ECN フィールドがあり、TCP ヘッダー側に ECE と CWR があります。

項目	場所	役割
ECT(0) / ECT(1)	IP ヘッダー	送信元が ECN 対応パケットとして送っていることを示す
CE	IP ヘッダー	途中のルーターや AQM が輻輳を検知したことを示す
ECE	TCP ヘッダー	受信側が CE を受け取ったことを送信側へ通知する
CWR	TCP ヘッダー	送信側が輻輳ウィンドウを減らしたことを通知する

IP ヘッダーの ECN フィールドは 2 ビットで、Not-ECT、ECT(0)、ECT(1)、CE の 4 状態を表します。ECT(0) または ECT(1) で送られたパケットに対し、経路上の装置が輻輳を通知するときに CE へ変更します。

つまり、ルーターが直接 TCP の ECE を立てるわけではありません。ルーターや AQM は IP ヘッダー側の CE を立て、受信側 TCP がそれを ECE として送信側へ返します。送信側は輻輳制御を行い、CWR でそれを知らせます。

SYN に付く ECE/CWR は輻輳通知ではない

誤解しやすいのは、接続開始時の SYN でも ECE と CWR が出てくることです。ECN を使いたい TCP 実装では、クライアント側の SYN に ECE と CWR が付くことがあります。

• クライアントからの SYN: SYN + ECE + CWR
• サーバーからの SYN/ACK: SYN + ACK + ECE
• 以降の通信: ECN が合意された場合、通常の ECN 動作へ移る

この段階の ECE と CWR は、輻輳が発生したという意味ではありません。ここでは、ECN を使えるかどうかを両端で確認するための能力交渉として使われています。

したがって、パケットキャプチャで SYN + ECE + CWR が見えたとしても、それだけで攻撃や異常パケットと判断するのは危険です。ECN に対応した通常の TCP スタックが、接続開始時に出している可能性があります。

通信中の ECE/CWR は輻輳制御のために使われる

接続時の ECN 交渉が終わると、ECE と CWR は本来の輻輳通知のために使われます。流れとしては次のようになります。

• 送信側は、ECN 対応の通信であることを IP ヘッダー側の ECT で示す
• 途中のルーターや AQM が輻輳を検知すると、パケットを捨てる代わりに IP ヘッダーの CE を立てる
• 受信側は CE を受け取ると、ACK に ECE を付けて送信側へ知らせる
• 送信側は輻輳ウィンドウを減らし、CWR を付けて制御を適用したことを返す

ここでの ECE は「輻輳を経験したパケットを受け取った」という通知であり、CWR は「輻輳通知を受けて送信側がウィンドウを減らした」という通知です。

つまり、通信中の ECE/CWR は、ネットワークが壊れていることを直接示すフラグではありません。むしろ、ECN が意図通りに動き、パケットロスに頼らず輻輳を伝えようとしている可能性があります。

異常と見るべきケース

ECE/CWR が見えたこと自体は、異常ではありません。ただし、次のような状況では、ECN そのものではなく周辺装置や経路上の挙動を疑う必要があります。

• SYN + ECE + CWR の後に接続が成立しない
• 特定のファイアウォール、ロードバランサー、NAT、プロキシを経由したときだけ失敗する
• ECN を無効化すると通信が安定する
• IDS/IPS が TCP flag anomaly として検知している
• 経路上の一部装置だけが ECN 付き TCP セグメントを不正なフラグの組み合わせとして扱う

この場合に見るべきなのは、ECE/CWR というフラグ名そのものではなく、どの装置がその通信をどう扱っているかです。古いミドルボックスや単純な TCP フラグ検査では、ECN の能力交渉を不正な組み合わせとして扱うことがあります。

なぜファイアウォールや IDS が誤検知しやすいのか

ECE/CWR が厄介なのは、同じ TCP フラグが接続開始時と通信中で異なる意味を持つことです。接続開始時は ECN の能力交渉、通信中は輻輳通知と輻輳制御の応答です。

古いファイアウォール、IDS、IPS、または TCP フラグの組み合わせを単純に検査する装置では、SYN + ECE + CWR を「見慣れない SYN」として扱うことがあります。しかし RFC 3168 の文脈では、これは ECN セットアップのための正当なパターンです。

もちろん、実運用ではすべての環境で ECN を有効にすべきだという話ではありません。重要なのは、ECE と CWR を見たときに、まず ECN の交渉なのか、データ通信中の輻輳通知なのかを切り分けることです。

パケットキャプチャで見るときの考え方

パケットキャプチャで確認する場合、ECE/CWR だけを見るのではなく、どのフェーズの TCP セグメントなのかを確認します。

• SYN と一緒に出ている場合は、ECN の能力交渉である可能性が高い
• SYN/ACK と一緒に ECE が出ている場合は、サーバー側が ECN 対応を返している可能性が高い
• データ通信中の ACK に ECE が出ている場合は、CE を受け取った通知である可能性がある
• 送信側から CWR が出ている場合は、輻輳ウィンドウを減らした応答として見る
• 通信失敗と同時に出ている場合は、経路上のミドルボックスやポリシーを確認する

つまり、ECE/CWR はフラグ名だけで判断せず、SYN なのか、ACK なのか、IP ヘッダーの ECN フィールドがどうなっているのかと合わせて見る必要があります。

Wireshark と tcpdump で ECE/CWR を確認する

Wireshark では、表示フィルターに tcp.flags.ece == 1 || tcp.flags.cwr == 1 を指定すると、ECE または CWR が立っている TCP セグメントを抽出できます。抽出後は tcp.flags.syn と tcp.flags.ack も見て、接続開始時の能力交渉なのか、通信中の輻輳通知なのかを分けます。

tcpdump のキャプチャフィルターで絞り込む場合は、TCP フラグバイトの ECE と CWR に相当するビットを tcp[13] & 0xc0 != 0 で確認できます。この条件は ECE/CWR のあるパケットを抽出するだけなので、異常判定には使わず、前後の 3 ウェイハンドシェイクや IP ヘッダーの ECN フィールドと合わせて読みます。

RFC 上の位置づけ

ECN の基本的な仕様は RFC 3168 で整理されています。RFC 3168 は TCP/IP に ECN を追加し、IP ヘッダー側の ECN フィールドと TCP ヘッダー側の ECE/CWR の使い方を定義しています。

その後、ECN 周辺の実験や拡張の制約を緩和する RFC 8311 などもあります。実装や詳細な挙動を追う場合は、RFC 3168 だけでなく、後続 RFC で何が更新されているかも確認した方が安全です。

参考書籍

まとめ

ECE と CWR は、単に珍しい TCP フラグではありません。ECN によって、パケットロスに頼らず輻輳を通知するための仕組みです。

特に重要なのは、SYN + ECE + CWR は輻輳通知ではなく、ECN を使うための能力交渉として現れるという点です。ここを誤解すると、正常な TCP 接続を不正なフラグの組み合わせとして誤検知してしまいます。

ECE/CWR を見るときは、フラグ単体ではなく、TCP の接続フェーズ、IP ヘッダーの ECN フィールド、ファイアウォールや IDS の解釈を合わせて確認することが重要です。見慣れないフラグをすぐ異常と決めるのではなく、ECN の交渉なのか、通信中の輻輳通知なのか、あるいはミドルボックスとの相性問題なのかを分けて見るべきです。