TCP フラグ ECE/CWR とは何か – ECN の交渉と輻輳通知を整理する

TCP ヘッダーには、SYN、ACK、FIN、RST などのよく知られたフラグがあります。その中で、少し意味がわかりにくいのが ECE と CWR です。

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

この記事では、SYN + ECE + CWR が見えたときに、それを異常な TCP フラグとして見るべきなのか、それとも ECN の能力交渉として見るべきなのかを整理します。

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

まず押さえるべき点は、ECE と CWR は TCP 単体で完結するフラグではないということです。ECN では、IP ヘッダー側に ECN フィールドがあり、TCP ヘッダー側に ECE と CWR があります。

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

つまり、ルーターが直接 TCP の ECE を立てるわけではありません。ルーターは 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 で示す
• 途中のルーターが輻輳を検知すると、パケットを捨てる代わりに IP ヘッダーの CE を立てる
• 受信側は CE を受け取ると、ACK に ECE を付けて送信側へ知らせる
• 送信側は輻輳ウィンドウを減らし、CWR を付けて制御を適用したことを返す

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

なぜファイアウォールや 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 フィールドがどうなっているのかと合わせて見る必要があります。

RFC 上の位置づけ

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

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

• RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP
• RFC 8311: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation

参考書籍

関連する記事

• VyOS MSS 設定 – TCP MSS 調整の基本
• TFTP の仕組みとファイアウォール設計上の考慮点
• DNS クエリに頼ったセキュリティ制限は DoH で簡単に突破される可能性

まとめ

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

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

ECE/CWR を見るときは、フラグ単体ではなく、TCP の接続フェーズ、IP ヘッダーの ECN フィールド、ファイアウォールや IDS の解釈を合わせて確認することが重要です。