ネットワーク WG
Request for Comments: 3360
BCP: 60
分類: Best Current Practice

S. Floyd
ICIR
2002年 8月
 

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 パケットを(4 回を上限として)再送します。

我々は、「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 と byte 14 についての以前の規定

        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 実装者には、下記の理由によって、これまで、これらの対処策を採用しない者がいました。:

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

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.  規範的参考文献

[RFC793]   Postel, J.,
"Transmission Control Protocol - DARPA Internet Program Protocol Specification",
STD 7, RFC 793, 1981年 9月.
 
[RFC1122]  Braden, R.,
"Requirements for Internet Hosts -- Communication Layers",
STD 3, RFC 1122, 1989年10月.
 
[RFC1812]  Baker, F.,
"Requirements for IP Version 4 Routers",
RFC 1812, 1995年 6月.
 
[RFC2026]  Bradner, S.,
"The Internet Standards Process -- Revision  3",
BCP 9, RFC 2026, 1996年10月.
 
[RFC2481]  Ramakrishnan, K. and S. Floyd,
"A Proposal to add Explicit Congestion Notification (ECN) to IP",
RFC 2481, 1999年 1月.
 
[RFC2873]  Xiao, X., Hannan, A., Paxson, V., and E. Crabbe,
"TCP Processing of the IPv4 Precedence Field",
RFC 2873, 2000年 6月.
 
[RFC2979]  Freed, N.,
「インターネットファイアウォールのふるまいとその要件(Behavior of and Requirements for Internet Firewalls)」,
RFC 2979, 2000年10月.
 
[RFC3168]  Ramakrishnan, K., Floyd, S.  and D. Black,
"The Addition of Explicit Congestion Notification (ECN) to IP",
RFC 3168, 2001年 9月.

 

10.  参考情報

[B01]      Bellovin, S.,
"A "Reason" Field for ICMP "Administratively Prohibited" Messages",
作業中.
 
[Cou01]    Scott Courtney,
"Why Can't My 2.4 Kernel See Some Web Sites?", Enterprise Linux Today, 2001年 4月17日. 
URL "http://eltoday.com/article.php3?ltsn=2001-04-17-001-14-PS".
 
[ECN]      "The ECN Web Page",
URL "http://www.icir.org/floyd/ecn.html".
 
[FIXES]    ECN-under-Linux Unofficial Vendor Support Page,
URL "http://gtf.org/garzik/ecn/".
 
[Floyd00]  Sally Floyd,
Negotiating ECN-Capability in a TCP connection, 2000年10月 2日, email to the end2end-interest mailing list. 
URL "http://www.icir.org/floyd/papers/ECN.Oct2000.txt".
 
[Kelson00] Dax Kelson,
Linux kernel メーリングリスト宛てに送られたノート,
2000年 9月10日.
 
[QUESO]    Toby Miller,
Intrusion Detection Level Analysis of Nmap and Queso, 2000年 8月30日. 
URL "http://www.securityfocus.com/infocus/1225".
 
[Ste94]    Stevens, W.,
"TCP/IP Illustrated, Volume 1: The Protocols",
Addison-Wesley, 1994年.
 
[SFO01]    FreeBSD ipfw Filtering Evasion Vulnerability, Security Focus Online, 2001年 1月23日. 
URL "http://www.securityfocus.com/bid/2293".
 
[TBIT]     Jitendra Padhye and Sally Floyd, Identifying the TCP Behavior of Web Servers, SIGCOMM, 2001年 8月. 
URL "http://www.icir.org/tbit/".

 

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.