English

不適切なTCP Resetは有害である
(Inappropriate TCP Resets Considered Harmful)

このメモの位置づけ

この文書は、 インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、 改善するために議論と示唆を求めるものです。 このメモの配布に制限はありません。

著作権表記

Copyright (C) The Internet Society (2002).  All Rights Reserved.

要旨

本書は、一定のTCP SYNパケット(特に、 TCPヘッダーのReservedフィールド中にフラグが設定されたパケット)を受信したとき、 TCPコネクションを不適切にResetする数多くのファイアウォールがインターネット上にあるので書かれました。 本書において、我々は、「この実践は、TCP標準に準拠しておらず、かつ、 TCP Resetについての不適切な過負荷である」と主張します。 我々は、また、この長期的な結末と、 インターネットインフラストラクチャの発展に対する障壁となる同様な活動も考慮します。

1. はじめに English

TCPは、TCPコネクションをリセットするために、 TCPヘッダー中のRST (Reset)ビットを使います。 Resetは、例えば、 存在しないコネクションに対するコネクションリクエストに応じて適切に送られます。 TCP Resetの受信者は、そのTCPコネクションを中止させ、 そのアプリケーションに通知します [RFC793, RFC1122, Ste94]。

残念ながら、現在のインターネットにおいて、 数多くのファイアウォールやロードバランサーは、 TCPヘッダー中のReservedフィールドのフラグを使うTCP SYNパケットに応じてResetを送っています。 下記 3章では、 ECN対応可能ホストからのTCP SYNパケットに応じてResetを送るファイアウォールの具体例を検討します。

本書は、Webサーバやファイアウォールのシステム運用管理者向けに、 バグ修正の配備 [FIXES] を促進する努力において、この問題を情報提供するために書かれました。 本書の2番目の目的は、 「より一般的な、インターネットのプロトコルの進歩における、 このような中間ボックスのふるまいによる長期的な結末を考慮すること」にあります。

2. TCP Resetの経緯 English

この章は、TCP標準におけるTCP Resetの利用についての簡潔な経緯説明を提供し、 「TCPヘッダー中のReservedフィールドのビットを使うSYNパケットに応じてResetを送ることは、 非準拠のふるまいである」と主張します。

RFC 793 [RFC793] には、 1981年9月におけるTCPの当初の仕様が書かれています。 本書は、TCPヘッダー中のRSTビットを規定し、「resetは、 古い重複したコネクション開始が、 TCPの3ウェイハンドシェイクにおいて混乱をもたらすことを防ぐために考案されたこと」について説明しています。 Resetは、また、ホストが、 もはや存在しないTCPコネクションについてのデータを受信するとき、 使われます。

RFC 793は、その5章において、下記のことを述べています。：

「一般的ルールとして、Reset (RST)は、 その外観が現在のコネクションのために意図されたものではないセグメントが到着するときには常に送られなければならない。 Resetは、これが該当するか不明な場合、送られてはならない。」

RFC 1122は、RFC 793を「改訂・修正するものであり、補足するもの」です。 RFC 1122には、TCP Reservedフィールド中のフラグに応じてResetを送信することについて、 あるいは、Resetを送信しないことについて、 具体的には何も書かれていません。

それゆえ、「単にSYNパケットがTCPヘッダー中のReservedフラグを使っているからといってResetを送信することが許容可能であること」を示唆することは、 RFC 793もしくはRFC 1122には無く、RFC 793は、 この理由でResetを送信することを明示的に禁じています。

RFC 793とRFC 1122の両方は、 Jon Postelの有名な「堅牢性原則」を含み、 RFC 791からの事項も含みます。： 「あなたが受信するものついては寛容であれ。 送信するものについては、保守的であれ。」 RFC 1122は、「この『堅牢性原則』は、 『ひとつの変なふるまいをするホストが多くの他のホストに対するインターネットサービスを不能にする可能性があるインターネット層において特に重要であること』」を重ねて強調しています。 RFC 1122における「堅牢性原則」の検討は、 「変更の採用可能性については、 インターネットホストのすべてのレベルのソフトウェアにおいて設計されなければならない」とも言明しています。 「受信するものついては寛容であれ」という原則は、 ファイアウォールの分野に(必ずしも)うまく適用されませんが、 『変更の採用可能性』の論点は、それでもやはり、極めて重要です。 その変更は、インターネットが新しいアプリケーション、 プロトコルおよび機能をサポートするように発展する能力を完全にはブロックしてしまうことなく、 正規とは言えないセキュリティの関心事を防ぐことにあります。

2.1. TCP Reservedフィールド English

RFC 793には、「TCPヘッダー中のReservedフィールドは、 将来の利用のために確保されており、 ゼロでなければならない」と書かれています。 この文書の他の部分と、より整合するように書き直すならば、 「Reservedフィールドは、将来の標準化活動によって規定されない限り、 送信されたとき、ゼロである必要があり、受信されたとき、 無視される必要がある」ということであったはずです。 しかし、RFC 793中の記述は、上記の章において説明したような、 非ゼロのReservedフィールドをもつTCPパケットに応じたResetの送信を許容していません。

2.2. インターネットファイアウォールのふるまいと要件 English

「インターネットファイアウォールのふるまいと要件」についての情報提供(Informational) RFC 2979 [RFC2979] には、下記のことが書かれています。：

「アプリケーションは、 ファイアウォールが在る場合でも正しく動作し続けなければならない。 これは、下記の透過性ルールに翻訳されます。： ファイアウォールや、 あらゆる関連するトンネリング設備(あるいはアクセス交渉設備)の導入は、 そのファイアウォールが無かった場合、 動作する正規かつ標準準拠の用法の意図しない失敗をもたらしてはならない(MUST NOT)。」

「この要求に対する必要不可欠な類推は、 『このような失敗が実際に起きたとき、その問題に対応することは、 ファイアウォールや関連するソフトウェアの責任となる』ということである。： 既存の標準プロトコルの実装の変更も、 そのプロトコル自体の変更も、 必須であってはならない(MUST NOT)。」

「『この要件は、正規のプロトコルの用法と、 いわれのない失敗にのみ適用されること』に注意。 (ファイアウォールは、 (試みられているアクセ宇が標準準拠であるか否かにかかわらず)サイトが不正と見なす、 あらゆる種類のアクセスをブロックすることができます。)」

我々は、「RFC 2979は、情報提供RFCであること」を指摘しておきます。 インターネット標準化過程についてのRFC 2026は、 その4.2.2節において、下記のことを述べています。： 「情報提供(Informational)の規定は、 インターネットコミュニティへの一般的な情報提供のために発行されており、 インターネットコミュニティの合意事項もしくは推奨事項を表現するものではありません [RFC2026]。」

2.3. 混雑制御メカニズムとしてのReset送信 English

ファイアウォールやホストには、 混雑制御メカニズムとしてのSYNパケットに応じてResetを送るものがあります。 例えば、 ファイアウォールが待ち受けている(listen)キュー(queue)が満杯のときです。 これらのResetは、TCP Reservedフィールドの中身を考慮せずに送られます。 おそらく、混雑制御メカニズムとしてのResetの利用に応じて、 いくつかの普及しているTCP実装は、 直ちにResetに応じてSYNパケットを( 回を上限として)再送します。

我々は、 「TCP Resetが混雑制御メカニズムとしては使われないこと」を推奨します。 なぜならば、これは、Resetメッセージの処理に過負荷をかけ、 必然的にTCP実装によるResetに応じた、 より攻撃的なふるまいをもたらすからです。 我々は、「単に、SYNパケットを棄却することが、 混雑に対する最も効果的な応答であること」を示唆します。 TCPの送信者は、RTO (Retransmission Timeout：再転送タイムアウト)についてのデフォルト値を使って、 各再転送後にその再転送タイマーを戻して、そのSYNパケットを再転送します。

2.4. 優位なフィールドに対するResetについての変更 English

RFC 793には、5章の中に下記のことが書かれています。：

「入り方向のセグメントがセキュリティのレベル、 もしくはコンパートメントをもつ場合、もしくは、 必ずしもレベルやコンパートメントに合致しない「優先権(precedence)」をもち、 優先権がそのコネクションを要求した場合、 Resetが送られ、コネクションは、CLOSED状態になる。」

「優先権(precedence)」は、 IPヘッダーにおける(古い)ToSフィールド中の(古い)Precedenceフィールドを指します。 「セキュリティ」と「コンパートメント(compartment)」は、 廃止されたIPセキュリティオプションを指します。 これが書かれたとき、これは、 RFC 793中に書かれている「Resetは、外観上、 現在のコネクションとして意図されていないセグメントが到達するときにのみ送られる必要がある」というガイドラインと整合していました。

「IPv4の優位なフィールドのTCP処理」についてのRFC 2873 [RFC2873] は、優位なフィールドが変更されたとき、 Resetの送信によって提起された具体的な問題を検討しています。 RFC 2873(現在は、Proposed Standard)は、 「TCPは、すべての受信したセグメントの優先権を無視しなければならず、 その優先権(precedence)フィールドにおける変更に応じてResetを送ってはならない」と規定しています。 我々は、「この論点について、 非ゼロのTCP Reservedフィールドをもつセグメントに応じたResetの送信は、 決して許されないこと」を明確にするために、これをここで検討します。

2.5. Illegal Option Lengthsに対するReset English

RFC 1122 [RFC1122] には、 TCPオプションについて、 下記のことが4.2.2.5節に書かれています。：

「TCPは、 あらゆるセグメント中のTCPオプションを受信することができなければならない(MUST)。 TCPは、オプションとして、長さ(length)フィールドをもつことと想定して、 実装していない、いかなるTCPオプションもエラーとすることなく、 無視しなければならない(MUST)。 (将来規定されるすべてのTCPオプションは、 長さ(length)フィールドをもつ。) TCPは、クラッシュすることなく、 不正なオプション長(例：ゼロ)を扱うことに備えなければならない(MUST)。 示唆される手順は、そのコネクションをリセットし、 その理由を記録することである。」

これは、理にかなっています。 なぜならば、TCP受信者は、 不正なオプション長のTCPオプションをもつセグメント上のデータのResetを解釈できないからです。 繰り返しになりますが、我々は、 「この論点は、非ゼロのTCP Reservedフィールドをもつセグメントに応じてResetの送信を決して許容しないこと」を明確にするために、 これをここで検討します。

3. ECNの具体例 English

この章には、ECN (Explicit Congestion Notification)の簡潔な説明が一般的に書かれているとともに、特に、 ECN-setup SYNパケットの説明が書かれています。

インターネットは、「エンド to エンド」の混雑制御に基づいており、 歴史的に、インターネットは、 ルーターが混雑をエンドノードに対して示すための唯一の手法として、 パケット棄却を使ってきました。 ECNは、ルーターがパケットを棄却する代わりに、 混雑についてエンドノードに知らせるためのIPパケットヘッダー中のビットをセットできるようにするために、 IPアーキテクチャに最近、追加されたものです。 ECNは、そのトランスポートのエンドノード間の協調を要求します。

ECN仕様(RFC 2481)は、1999年1月から2001年6月まで「実験的(Experimental) RFC」であったものであり、 このとき見直された文書 [RFC3168] がProposed Standardとして承認されました。 ECNについてのより詳細な情報は、 ECNのWebページ [ECN] から入手可能です。

ECNのTCPにおける利用は、「TCPの両端は、 ECNの利用をサポートするようにアップグレードされていること」と、 「両端のノードが、 ECNをこの特定のTCPコネクションにおいて使うことに合意すること」を要求します。 このTCPの両端ノード間のECNサポートについての交渉は、 TCPヘッダー中のReservedフィールド から割り当てられた2つのフラグを使います [RFC2481]。

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

|               |                       | U | A | P | R | S | F |

| Header Length |        Reserved       | R | C | S | S | Y | I |

|               |                       | G | K | H | T | N | N |

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

図1： TCPヘッダーのbyte 13とbyte14についての以前の規定

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

|               |               | C | E | U | A | P | R | S | F |

| Header Length |    Reserved   | W | C | R | C | S | S | Y | I |

|               |               | R | E | G | K | H | T | N | N |

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

図2：TCPヘッダーのbyte 13とbyte 14についての現在の規定(RFC 3168より)

TCPヘッダー中の2つのECNフラグは、 TCPヘッダーのReservedフィールド中の最後の2つのビットによって規定されています。 TCPヘッダーのReservedフィールド中の9番ビットは、 ECE (ECN-Echoフラグ)として割り当てられており、 8番ビットは、CWR (Congestion Window Reduced)フラグとして割り当てられています。 ECNの用法を交渉するために、そのTCP送信者は、 「ECN-setup SYNパケット(ECEとCWRのフラグがセットされたTCP SYNパケット)」を送ります。 他端のTCPホストがECNをこのコネクションについて使うことを望む場合、 これは、「ECN-setup SYN-ACK パケット(ECEフラグがセットされており、 CWRフラグがセットされていないTCP SYNパケット)」を送ります。 そのようにしないと、他端にあるTCPホストは、 ECEフラグもCWRフラグもセットされていないSYN-ACKパケットを返します。

そこで、TCP Resetに戻ります。 ECNを交渉しているTCPホストがECN-setup SYNパケットを送るとき、 古いTCP実装は、Reservedフィールド中のそれらのフラグを無視し、 応答として、プレインなSYN-ACKパケットを送信することが期待されます。 しかし、インターネットには、 ECN-setup SYNパケットに対してResetで応答する壊れたファイアウォールやロードバランサーがあります。 ECN対応可能なエンドノードの配備に従うと、 広く「ECN対応可能なホストは、 数多くのWebサイトにアクセスできない [Kelson00]」という不満がありました。 これは、Linuxコミュニティによって調査されてきたことであり、 データについては、2000年9月から2002年3月まで「TBITプロジェクト [TBIT]」によって採取され、 "Enterprise Linux Today" [Cou01] にある読み物において検討されています。 問題の機器のいくつかは、識別されており、あるWeb ページ [FIXES] には、非準拠製品の一覧と、 そのベンダーによって投稿された修正コードが掲げられています。 2002年3月に(6ヶ月後に、ECNは、Proposed Standardとして承認されました。)、ECN-setup SYNパケットは、 テストされた12,364のWebサイトの内の203からのResetによって答えられ、 ECN-setup SYNパケットは、420のWebサイトにおいて棄却されました。 TCPのReservedフィールド中のフラグを使っているパケットをブロックするソフトウェアの導入は、 後でそのソフトウェアをアンインストールするよりも、かなり楽です。

3.1.ECN：対処策 English

壊れた機器に直面したとき、接続性を維持管理するための対処策は、 [Floyd00] に記述され、 RFC 3168中にTCP実装に含めることができる手順として規定されました。 我々は、以下、この対処策を簡潔に記述します。

ECN-setup SYNパケットの転送に応じてResetを受信するという不完全な機器が存在する状況においても、 堅牢な接続性を提供するために、TCPホストは、 CWRとECEがクリアされたSYNを再送することができます。 これは、ECNを使わずに確立されたTCPコネクションをもたらします。 これは、また、「そのECN対応可能TCPホストが、 最初の正規のResetに正しく応答しない」という不幸な結果ももたらします。 2番目のResetが、CWRとECEがクリアされた2番目のSYNに応じて送られた場合、 そのTCPホストは、そのコネクションを中止することによって、 正しく応答する必要があります。

同様に、通常のSYN再転送タイムアウト間隔内にECN-setup SYNに対する応答を受信しないホストは、 そのSYNおよび以降のあらゆるSYN再転送をCWRとECEをクリアして再送できます。 当初のSYNが失われることをもたらす通常のパケットロスを克服するために、 その発信元ホストは、諦めて、 CWRとECEのビットがクリアされたSYNを再転送する前に、ひとつ、もしくは、 複数のECN-setup SYNパケットを再転送する可能性があります。

TCP実装者には、下記の理由によって、これまで、 これらの対処策を採用しない者がいました。：

• 対処策は、ECN対応可能ホストがSYNパケットに応じて受信した最初の正規のResetに正しく対応しないことをもたらす。
• 対処策は、最初のSYNもしくはSYN-ACKパケットがネットワーク内で棄却された場合、 ECNを不能にすることによって、 壊れた機器が無い環境においてECN機能を制限する。
• 多くの場合、 ECN-setup SYNパケットを棄却する壊れた機器があるときの対処策は、 その遠隔サーバーとの接続性が確立するまでに6秒以上の遅延をもたらす。 この壊れた機器の面倒をみることによる対処策は、暗黙の内に、 この遅延と、 この遅延をもたらす壊れた機器の両方を受容することとして、 判定されてきた。

このような対処策として、ひとつの可能性は、 ユーザによって設定可能とすることです。

Resetに応じて細工されたSYNパケットを再送するという対処策に不可避な結末は、 さらにTCP Resetの処理を蝕むことです。 それゆえ、ボックスがResetを送るとき、 そのResetを受信するTCPホストは、単に、 そのTCPヘッダー中のECN関連フラグ、もしくは、 より根本的な何らかの問題に起因して、 Resetが送信されたか否かを知りません。 それゆえ、そのTCPホストは、TCPヘッダー中にECN関連フラグ無しに、 そのTCP SYNパケットを再送します。 この中間ボックスからエンドノード宛てのクリアな通信の不在の究極的な結末は、 トランスポートプロトコルのために仕様とされた通信の拡大されたスパイラルとなる可能性があります。 なぜならば、エンドノードは、「どのパケットが他端宛てに転送されるか、 また、転送されないか？」を判定する過程において、 できる限り機能性を犠牲にしないようにすることを試みるからです。 これは、6.1節 において、 より詳細に検討されます。

4. インターネットインフラストラクチャの正しい進展に対する障害と闘う際に English

「この不適切なResetの論点が(私にとって)重要であること」の理由のひとつは、 「これは、(幸い、ECNの配備を完全にはブロックしなかったことを通じて)インターネットにおけるECNの配備を複雑化してしまったこと」です。 将来のECNの有効性に対して、不要な障害も加わりました。

しかし、2番目の「なぜ、この論点が重要であるのか？」の、 より一般的な理由は、 「インターネットにおける正規のTCPパケットを棄却する機器の存在は、 完全にECNの論点とは別に、 将来のTCPの進化を制限してしまうものである」からです。 すなわち、 TCPヘッダー中のReservedフラグを使うTCPパケットを棄却する機器の広範な配備は、 これらのReservedフラグの内のどれかを使う新しいメカニズムの配備を効果的に妨げてしまう可能性があります。 これらの新しいメカニズムがIETFの「実験的(Experimental)」もしくはProposed Standardの文書ステータスの保護をもつ場合、これは問題となりません。 なぜならば、インターネット中の壊れた機器は、パケットを棄却する前に、 そのプロトコルの現在の状況をルックアップすることを止めないからです。 TCPは、良いものであり、有用ですが、 インターネットにおける壊れた機器の配備が、 Reservedフラグを将来のTCPの進展のために使う能力をもたずに、 TCPを現在の状態に「凍結すること」をもたらすことは、残念なことです。

具体的に、ECNを交渉することを試みるTCP SYNパケットをブロックする中間ボックスの場合、 3.1節に記述した対処策は、「エンドノードは、 なおも接続性を確立できること」を確保するのに十分です。 しかし、これからの1～2年で標準化されるTCP Reservedフィールドの追加的な利用と、これらの追加的な利用は、 Resetを送信する中間ボックスは、うまく共存できない可能性があります。 コネクションが生きている期間中に変化するパスと、 古いパスと新しいパス上の中間ボックスが、まさに、 「TCP Reserved フィールド中のどのフラグをブロックして、 どのフラグをブロックしないか？」について異なるポリシーをもつ場合に起こりうる困難を考慮しましょう。

より広い視野からは、不適切なResetを送るWebサーバー、あるいは、 ファイアウォールの存在は、 インターネットの将来の発展を制限するインターネットにおける機能の一例にすぎません。 これらの小さな制約事項がすべて合わさった影響は、 インターネットアーキテクチャの開発に対する相当な障害をもたらします。

5. トランスポートプロトコルについての緒論点 English

トランスポートプロトコルの設計者にとっての試練は、 「トランスポートプロトコルは、ネットワーク中のファイアウォール、 ノーマライザー(Normalizer)および他の中間ボックスの未知かつ任意に見える活動から自らを防護する必要があること」です。 現時点において、TCPについて、これは、 ResetがECN-setup SYNパケットに応じて受信されたとき、 非ECN-setup SYNを送ることを意味します。 トランスポートプロトコル側における防護機能は、 データトラフィックにおいて利用する前における、 それらのフラグを使ってパケットをブロックしてしまう中間ボックス対策としてのSYNパケット中のReservedフラグの利用を含む可能性があります。 「トランスポートプロトコルは、そのコネクションの存続期間において、 パス上の中間ボックスからの干渉についてチェックするために、 さらなるチェックも追加しなければならないこと」は、ありえます。

ECNについての標準文書であるRFC 3168には、 「ネットワーク内におけるECNフィールドについての変更の可能性」についての18章に広範な検討がありますが、 TCPヘッダーについて可能な変更について、下記のことが書かれています。：

「本書は、 ネットワーク中におけるトランスポートヘッダーの変更によってもららされる潜在的な危険を考慮しません。 我々は、『IPsecが使われているとき、そのトランスポートヘッダーは、 トンネルモードとトランスポートモード[ESP, AH] の両方において防護されること』を指摘します。」

(下記6.2節において検討されているような)ファイアウォールのよるネットワーク中のトランスポートレベルのヘッダーについての今般の変更によって、 将来のプロトコル設計者は、もはや、 ネットワーク内におけるトランスポートヘッダーに対する変更の影響の可能性を無視する余裕をもたない可能性があります。

トランスポートプロトコルは、また、中間ボックスが、 この形態のICMPの「宛先到達不能(Destination Unreachable)」メッセージを「そのパケットは、 許可されていない機能 [RFC1812] を使っていること」を示すために使い始めた場合、 ICMPコード：「通信は運用管理的に禁止されている(Communication Administratively Prohibited)」に対して何らかのかたちで応答しなければなりません。

6. 中間ボックスについての諸論点 English

どこかの中間ボックスが、 パケットがその中間ボックスによって許可されていない機能を使うことを理由に、 いくつかのパケットを棄却しようとしているとき、 「このような処理がある場合、どのように、中間ボックスは、 この処理についての理由をエンドノード宛てに通信する必要があるか？」という、 より大きな論点が残ります。 別の文書にある、より深い考察からのひとつの示唆は、 「ファイアウォールは、『通信は運用管理的に禁止されている(Communication Administratively Prohibited) [B01] 』コードと共にICMP『宛先到達不能(Destination Unreachable)』メッセージを送ること」です。

我々は、「これは、いくつかの理由で、 理想的な解決策ではないこと」を告知します。 最初に、その逆に辿る経路上の中間ボックスは、 これらのICMPメッセージをブロックする可能性があります。 2番目に、ファイアウォール運用者には、 明示的な通信に反対する者がいます。 なぜならば、セキュリティポリシーについて、 あまりに多くの情報を明かすからです。 3番目に、 このようなICMPメッセージに対するトランスポートプロトコルのレスポンスは、 まだ規定されていません。

しかし、ICMPの「運用管理的に禁止(Administratively Prohibited)」のメッセージは、 明示的な通信を使うことを望むファイアウォールについて、 合理的な追加である可能性があります。 繰り返しになりますが、 別の文書において探求されるべきひとつの可能性は、 ICMP「運用管理的に禁止(Administratively Prohibited)」メッセージが追加的な情報をエンドホスト宛に運ぶように修正されることです。

我々は、「本書は、 完全なトランスポートプロトコルをブロックする中間ボックスを考慮しないこと」を指摘します。 我々は、「本書は、firewalled-off TCPポート宛のTCP SYNパケットに応じてResetを送信するファイアウォールに対応していないこと」も指摘します。 このようなResetの利用は、TCP Resetの趣旨と整合するように見えます。 本書は、そのトランスポートプロトコルの他のパケットの後に、 その中間ボックスが変更されないとき、 トランスポートプロトコル中の特定のパケットをブロックする中間ボックスによって引き起こされる問題のみを検討しています。 我々の面倒な事態は、「ひとたび特定の機能をブロックするために、 あるメカニズムがファイアウォールにインストールされると、 ネットワーク運用管理者がそのブロックを『アンインストール』するために相当な労力を要する可能性があること」です。 「ファイアウォールにおける拡張可能な設定は、全体的に、 より少ない痛みで将来のインシデントから復旧させる可能性があること」が示唆されてきました。 なぜならば、繰り返しになりますが、本書は、ファイアウォール、 より柔軟なファイアウォールの柔軟性の論点、および、 別の文書に書かれる「付随する可能性があるセキュリティリスク」についての、 より一般的な論点に対応していないからです。

6.1. 現在のファイアウォールにとっての選択肢 English

TCPヘッダー中の予約されたビットを使うTCPパケットを棄却するようにしているファイアウォールがあるとき、 ひとつの疑問は、「TCPコネクションがTCP送信者において、 その転送のタイムアウトを待つのに無駄に資源を浪費することを防ぐために、 ファイアウォールは、Resetも送る必要があるか否か？」です。 我々は、 「ファイアウォールがTCPパケットを棄却しなければならないのにもかかわらず、 TCP Resetを送ることは、不適切である」と主張します。 禁止された機能に応じてTCP Resetを送信することは、 あたり一帯に非生産的である懸念がある方法で、 現在のTCP Reset処理の過負荷を続けることになります。

一例として、2.3節において既に、 「ファイアウォールには、 混雑制御メカニズムとしてのTCP SYNパケットに応じてRresetを送るものがあること」を見てきました。 おそらく、これに応じて(もしくは、おそらく、 何か別のものに応じて)、正しいTCP実装には、 Resetに応じてSYNパケットを(4回を上限として)ただちに再送するものがあります。 標準に準拠した他のTCP実装は、Resetを受信した後、 SYNパケットを再送しません。 より攻撃的なTCP実装は、他者にとっての混雑を増加させますが、同時に、 いつかはそれ自体がきつくなっていく可能性も増加させます。 これらのfluid semanticsをTCP Reset用に与えると、人は、 より多くのTCP実装がECNについてもつ必要がある、 あらゆる論点とはまったく別に、 Resetに応じてSYNパケットの再送を始めることを期待する可能性があります。 明らかに、これは、 現在のコネクションのために意図されていないTCPパケットに応答するという当初の目的に使われるとき、 そのResetの有効性を低下させます。

我々が、この組み合わせにTCPヘッダー中のRreserved bitを使って、 TCPパケットに応答するファイアウォールによるTCP Resetの利用を加える場合、 これは、その水を濁らせます。 なぜならば、TCP Resetは、 混雑もしくは禁止された機能に起因して送られる可能性があるからであるか、 あるいは、パケットは、以前のTCPコネクションから受信されたからであり、 TCP実装(あるいは、より正しくは、TCP実装者)は、今や、 TCP Resetに応答してSYNパケットを再送する際に、 さらにより持続的(persistent)となる動機づけ要因(incentive)をもちます。 混雑している時間には最終的に厳しくなる掛け率を増大させるためにTCP SYNパケットを再送するという上記の動機づけ要因に加えて、 そのTCP Resetは、混雑ではなく、禁止された機能に起因する可能性があり、 それゆえ、そのTCP実装は、「どの機能が、 禁止されているか？」を明示的に判断するために、 異なる形態のSYNパケットを再送する可能性があります。 このようなTCP Resetの意味の頻繁な変更は、 ファイアウォールとエンドホストの間の手段および対策に、 両者にあまり便益をもたらすことがない、 持続的な展開を導くことが期待される可能性があります。

「禁止された機能の利用に起因して、 TCP SYNパケットを『棄却することは、 ResetがResetのsemanticsに過負荷をもたらす方法で、 パケット棄却のsemanticsの過負荷をもたらす」と主張される可能性があります。 これは、真です。 過負荷となったsemanticsについてのメッセージに責任を負うエンドシステムの観点から、 禁止されている機能について明示することが選好されます(それらのファイアウォール用に明示的な表示を使うことを望む何らかの理由によって)。 しかし、ファイアウォールが、Resetを送信するか、 単にそのパケットを棄却するかを選択しなければならない場合、我々は、 「単にパケットを棄却することは、 エンドホストに対策を採用する動機を与える観点から、 被害が少ない」と主張します。 「Resetを送信することなく、単にパケットを棄却することは、 その禁止された機能を使わずにSYNパケットを再送する際にTCPコネクションに遅延をもたらすこと」は、 真です。 しかし、Resetの送信は、 「将来のTCP実装にSYNパケットをresponseにおいて再送することの、 より奇異な(baroque)組み合わせをResetに加える動機づけ要因(incentive)を与える」という望まない長期的な影響をもちます。 なぜならば、そのTCP送信者には、 「そのResetが標準的な理由(混雑)によって送られたのか、 あるいは、option Xの禁止された機能もしくはTCPヘッダー中のreserved bit Yによって送られたのか」が分からないからです。

6.2. ネットワーク内でパケットヘッダーを変更することの複雑性 English

ECN-setup SYNパケットに応じてResetを送信するファイアウォールやECN-setup SYNパケットを棄却するファイアウォール以外にも、 デフォルトでTCP Reservedフィールド中のフラグ(ECNに使われる2つのフラグを含む)をゼロ化するファイアウォールもあります。 我々は、「場合によっては、これは、 意図しなかった望まない結末をもたらす可能性があること」を指摘します。

ファイアウォールが最初のSYNパケットの中のTCPヘッダー中のECN関連フラグをゼロ化する場合、 そのTCPコネクションは、ECNを使うことなくセットアップされ、 そのTCPヘッダー中のECN関連フラグは、 このコネクション中の以降のすべてのパケットにおいて、 すべてゼロ化されて送信されます。 これは、ECNをブロックするというファイアウォールの目的を達成する一方、 そのTCPコネクションがECNを使わずに効果的かつ円滑に進めることができるようにします。

何らかの理由でTCPヘッダ中のECN関連フラグがSYNパケットホストAからホストB宛の最初のSYNパケットにおいてゼロ化されていないが、 ファイアウォールが、 ホストBからto ホストA宛のSYN/ACKパケットに応答する際に、 それらのフラグをゼロ化する場合、その結末は、 このコネクションについての「エンド to エンド」の混雑制御を壊すことになる可能性があります。 ECN仕様は、 ネットワーク内でTCPヘッダーフィールドを任意にゼロ化することの存在を前提として、 堅牢な運用を確保するために書かれたものではありません。 なぜならば、当時、 そのプロトコル仕様の著者にとっては、 「プロトコル設計における要件」ではなかったからです。

同様に、TCPヘッダー中のECN関連フラグがSYNパケットにおいても、 SYN/ACKパケットにおいても、ゼロ化されていないが、 そのファイアウォールが、そのTCPコネクションにおいて、 以降のパケット中のこれらのフラグをゼロ化する場合、これも、また、 このコネクションについて、 「エンド to エンド」の混雑制御を破壊するという意図しなかった結末をもたらす可能性があります。 これらの可能性ある相互作用の詳細は、本書にとっては重要ではないので、 補遺中に記述されています。 しかし、「TCPヘッダー中のECN関連フラグ」と、「TCP Reservedフィールド中の他の4つのビットについての将来の利用」の両方についての我々の結論は、 「あるプロトコルに追加された新しい機能の利用をブロックできることがファイアウォールについて要求される場合、 これは、ファイアウォールコミュニティとプロトコル設計者の協働によって、 初期設計段階において、もっともうまく対応される」ということです。

7. 結論 English

我々の結論は、「単にそのパケットがTCP Reservedフィールド中のフラグを使っているからといって、 TCP SYNパケットにResetで応答することは、ファイアウォール、 ロードバランサーもしくはWebサーバーについての現在の標準に準拠していない」ということです。 より具体的には、これは、 単にECEとCWRのフラグがIPヘッダー中にセットされているからといって、 TCP SYNパケットにResetで応答することと整合しません。 我々は、ベンダーに、あらゆる非整合なコードについて、 入手可能な修正コードを作成することを促し、そして、 ISPやシステム運用管理者に対して、 彼らのWebサーバーやファイアウォールに、 これらの修正コードを採用することを促す可能性があります。

我々は、「これは、TCP Reservedフィールド中のフラグを使うパケットを勝手に棄却する中間ボックスについてのあらゆる標準を侵害する」と非難しているわけではなく、 我々は、「エンドノードに、 これらの活動についての理由を通知するための明確な手法を伴わない、 この種のふるまいは、TCPの開発に対して、 顕著な障害をもたらす可能性があること」を主張しているのです。 インターネットプロトコルの慎重な進化を許容すると同時に、 セキュリティを提供するという衝突する利害を和解させるために、 さらなる作業が明らかに必要とされています。

8. 謝辞 English

本書は、多くの人々による検討と活動の結果であるので、私は、 ここにすべてを反映して謝辞を述べることを試みます。 私の、具体的な感謝は、本書についてフィードバックしてくれた Ran Atkinson, Steve Bellovin, Alex Cannara, Dennis Ferguson, Ned Freed, Mark Handley, John Klensin, Allison Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Jamal Hadi Salim, Pekka Savola, Alex Snoeren, Dan Wingと、これらの論点を検討してくれたEnd-to-End Research Group, IABおよびIESGに宛てられます。 私は、何度もフィードバックしてくれたMikael Olssonに感謝します。 私は、 本書の以前のドラフトについてフィードバックしてくれた(概ね合意しないないようでしたが)"Firewall Wizards"メーリングリストのメンバーにも感謝します。

Dax Kelson, Alexey Kuznetsov, Kacheong Poon, David Reed, Jamal Hadi-Salim, Venkat Venkatsubraを含む数多くの人々との電子メールによる検討は、 インターネットにおける非準拠機器によって提起された論点に対応するものでした。 非準拠機器とは、TCP SYNパケットにECEとCWRのフラグをセットすることで応答しないものです。 我々は、TCP初期化手順について検討してくださったMark Handley, Jitentra Padhyeほかの皆さんに感謝します。

9. 規範的参考文献

10. 参考情報

11. セキュリティについての考慮事項 English

TCP中のReservedフラグを使うことの一般的なリスクのひとつは、 問題となるホストの設定についての追加的情報を提供することのリスクです。 しかし、TCPは、 十分に多くの流派(variant)やoptionsと共に「NmapやQuesoのようなポートスキャン用ツールは、 たとえReservedフラグを利用しなくてもホストの設定を識別する際に、 比較的うまく行う」と、現状どおりに十分に緩く規定されています。

「セキュリティについての考慮事項」と、 「通信は運用管理的に禁止されている(Communication Administratively Prohibited)」コードを伴う、可能性あるICMP宛先不当着(Destination Unreachable)メッセージについての他のすべての考慮事項は、 別の文書において検討されます。

従来のファイアウォールの関心は、 システムに対する認可されていないアクセスを防ぐこと、 エンドユーザ端末を破壊することからDoS攻撃や他の攻撃を防ぐこと、 および、「エンドシステムをバグが多いコードから防護すること」にありました。 我々は、TCPヘッダー中のReservedフラグの利用から報告されているセキュリティ脆弱性 [SFO01] を認識しています。 パケットフィルタは、 確立されたコネクションにおいてパケットを単に通過させるのではなく、 そのパケットのReservedフィールド中にECEフラグがセットされている場合、 確立されたコネクション中以外で、パケットを転送させることができます。 この脆弱性の攻略は、 普段は防護されているサービスに認可されていないリモートアクセスを許容してしまう可能性があります。 「TCPの実装は、 TCPヘッダー中のReservedフラグの利用に関してbuggyなコードをもつように見える」可能性もありますが、 我々は、今のところ、このような実装を認識していません。

残念ながら、見当違いなセキュリティの関心事(の存在)は、 本書の最初に記述した問題の理由のひとつです。 2000年8月の"Intrusion Detection Level Analysis of Nmap and Queso"についての読み物には、 TCPヘッダー中の最後のReserved 2 bitsにセットされたSYNパケットを送るポートスキャン用ツールであるQuesoについて記述されており、 下記のことが書かれています。： 「[QUESO] は、識別し易く、 [これらの2つのReservedビットとSYNビット] が TCPヘッダーの13番目のバイトにセットされている場合、 あなたは、『誰かが、あなたのネットワークについて、 悪意をもっていること』を知ります。」 TBITのWebページ上に文書化されているように、 TCPヘッダー中の2つのECN関連Reservedフラグを使っているSYNをブロックする中間ボックスは、 TCPヘッダー中の他のReservedフラグを使っているSYNをブロックしません。

ひとつの教訓は、「誰でも、単に、 公衆が入手可能なポートスキャンを行うツールにある機能を使うことによって、 新しいTCP機能を効果的に『攻撃』できること」のようです。 それゆえ、すべての種類の中間ボックスが、 その機能の利用をブロックするようにします。

12. 補遺：パケットヘッダーの変更による併発症 English

この章において、我々は、まず、 「TCPヘッダー中のECN関連フラグが、 ホストAからホストB宛ての最初のSYNパケットにおいてゼロ化されていないが、 ホストBからホストA宛の応答するSYN/ACKパケットにおいてゼロ化されている場合、 その結末は、このコネクションについて、 『エンド to エンド』の混雑制御を破壊するものである可能性があること」を示します。

「ホストAからのECN-setup SYNパケットは、 ホストBによって受信されますが、 ホストBからのECN-setup SYN/ACKは、下記の図3のように、 ネットワーク内でファイアウォールによって、 非-ECN-setup SYN/ACKに変更される」と想定します。 RFC 3168は、「結局、ACK パケットは、 SYN/ACKパケットにおいて受信したTCPフラグにechoする必要がある」とは規定していません。 なぜならば、設計者にしてみれば、「これらのフラグは、 そのネットワーク中で変更される」ようなことは無かったからです。

Host A                    Firewall or router             Host B
-----------------------------------------------------------------

Sends ECN-setup SYN     ---------------->  Receives ECN-setup SYN

                                       <- Sends ECN-setup SYN/ACK

             <- Firewall zeros flags

Receives non-ECN-setup SYN/ACK

Sends ACK and data      ---------------->   Receives ACK and data

                                    <- Sends data packet with ECT

                   <- Router sets CE

Receives data packet with ECT and CE

図3：ネットワーク内でクリアされたSYN/ACKパケット中のECN関連フラグ。

RFC 3168に従って、ホストAは、 非-ECN-setup SYN/ACKパケットを受信してきましたし、 データパケット上に、ECTをセットしてはなりません。 しかし、ホストBは、「ホストAが、非ECN-setup SYN/ACKパケットを受信したこと」を知りませんし、 ホストBは、ECTをデータパケットにセットする可能性があります。 RFC 3168は、ホストAに、 ホストBから受信したECTとCEコードポイントがIPヘッダー中にセットされたデータパケットに対して正しく応答することを要求していません。 それゆえ、そのデータ送信者(ホストB)は、 そのネットワークに起きている混雑について知らされない可能性があり、 それゆえ、「エンド to エンド」の混雑制御を侵害します。

次に、我々は、「TCPヘッダー中のECN関連フラグが、 SYNパケットにおいても、SYN/ACKパケットにおいてもゼロ化されていないが、 そのファイアウォールが、そのTCPコネクション中の後のパケットにおいて、 これらのフラグをゼロ化する場合、これは、 このコネクションについての「エンド to エンド」の混雑制御を破壊する」という意図しない結末になる可能性もあることを示します。 図4は、このシナリオを示します。

Host A                    Firewall or router             Host B

-----------------------------------------------------------------

Sends ECN-setup SYN     ---------------->  Receives ECN-setup SYN

Receives ECN-setup SYN/ACK <------------  Sends ECN-setup SYN/ACK

Sends ACK and data      ---------------->   Receives ACK and data

                                    <- Sends data packet with ECT

                   <- Router sets CE

Receives data packet with ECT and CE

Sends ACK with ECE ->

                      Firewall resets ECE ->

                                               Receives plain ACK

図4：ネットワーク中でクリアされたACKパケット中のECN関連フラグ。

ECN関連フラグは、図4中のシナリオについてECN-setup SYNおよびSYN/ACKパケット中のネットワークによって変更されておらず、 両端のノードは、ECNを使うことができるとともに、 IPヘッダーにおいてECNフィールド内にECTフラグをセットすることができます。 しかし、そのファイアウォールがNode AからNode B宛のACKパケットにおけるTCPヘッダー中のECEフラグをクリアする場合、 ノードBは、「その以前のデータパケットが、 そのネットワークにおいて遭遇された」という混雑について、 決して聴くことは無く、それゆえ、 このコネクションについての「エンド to エンド」の混雑制御を破壊します。

TCPにおけるECN nonceの利用がIETFにおいて標準化 [RFC3168] されたとき、追加的な複雑さが発生します。 なぜならば、これは、TCP Reservedフィールドを使って、 TCPデータ送信者宛のTCPデータの受信者からのフィードバックのための追加的なフラグの仕様を含む可能性があるからです。 ECN nonceについての主要な動機は、 「ネットワーク要素は、CEコードポイントを消去していないこと」と、 「データ受信者は、パケットの受信をCEコードポイントのセットで送信者宛に正しく報告していること」を検証するために、 そのデータ送信者にメカニズムを許容することです。

13. IANAについての考慮事項 English

本書中に「IANA についての考慮事項」は、ありません。

14. 著者のアドレス

Sally Floyd
ICIR (ICSI Center for Internet Research)

電話： +1 (510) 666-2989
EMail： floyd＠icir.org
URL： http://www.icir.org/floyd/

翻訳者のアドレス

独立行政法人 情報処理推進機構
セキュリティセンター
宮川 寧夫

miyakawa＠ipa.go.jp

15. 著作権表記全文

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.