|
[ 5] Inappropriate TCP Resets Considered Harmful
[引用サイト] http://www.ipa.go.jp/security/rfc/RFC3360JA.html
この文書は、インターネットの「現時点における最善の実践（ベストカレントプラクティス）」を示すものであり、改善するために議論と示唆を求めるものです。このメモの配布に制限はありません。
本書は、一定の TCP SYN パケット（特に、TCP ヘッダーの Reserved フィールド中にフラグが設定されたパケット）を受信したとき、TCP
コネクションを不適切に Reset する数多くのファイアウォールがインターネット上にあるので書かれました。本書において、我々は、「この実践は、TCP
標準に準拠しておらず、かつ、TCP Reset についての不適切な過負荷である」と主張します。我々は、また、この長期的な結末と、インターネットインフラストラクチャの発展に対する障壁となる同様な活動も考慮します。
TCP は、TCP コネクションをリセットするために、TCP ヘッダー中の RST（Reset）ビットを使います。Reset は、例えば、存在しないコネクションに対するコネクションリクエストに応じて適切に送られます。TCP
Reset の受信者は、その TCP コネクションを中止させ、そのアプリケーションに通知します [RFC793,
残念ながら、現在のインターネットにおいて、数多くのファイアウォールやロードバランサーは、TCP ヘッダー中の Reserved フィールドのフラグを使う
本書は、web サーバーやファイアウォールのシステム運用管理者向けに、バグ修正の配備 [FIXES]
を促進する努力における、この問題を情報提供するために書かれました。本書の 2 番目の目的は、「より一般的な、インターネットのプロトコルの進歩における、このような中間ボックスのふるまいの長期的な結末を考慮すること」にあります。
この章は、TCP 標準における TCP Reset の利用についての簡潔な経緯説明を提供し、「TCP ヘッダー 中の Reserved フィールドのビットを使う
ヘッダー中の RST ビットを規定し、「reset は、古い重複したコネクション開始が、TCP の 3 ウェイハンドシェイクにおいて混乱をもたらすことを防ぐために考案されたこと」について説明しています。Reset
は、また、ホストが、もはや存在しない TCP コネクションについてのデータを受信するとき、使われます。
「一般的ルールとして、Reset（RST）は、その外観が現在のコネクションのために意図されたものではないセグメントが到着するときには常に送られなければならない。Reset
Reset を送信することについて、あるいは、Reset を送信しないことについて、具体的には何も書かれていません。
それゆえ、「単にSYN パケットが TCP ヘッダー中の Reserved フラグを使っているからといって Reset を送信することが許容可能であること」を示唆することは、RFC
RFC 793 と RFC 1122 の両方は、Jon Postel の有名な「堅牢性原則」を含み、RFC 791 からの事項も含みます。： 「あなたが受信するものついては寛容であれ。送信するものについては、保守的であれ。」
RFC 1122 は、「この『堅牢性原則』は、『ひとつの変なふるまいをするホストが多くの他のホストに対するインターネットサービスを不能にする可能性があるインターネット層において特に重要であること』」を重ねて強調しています。RFC
1122 における「堅牢性原則」の検討は、「変更の採用可能性については、インターネットホストのすべてのレベルのソフトウェアにおいて設計されなければならない」とも言明しています。「受信するものついては寛容であれ」という原則は、ファイアウォールの分野に（必ずしも）うまく適用されませんが、『変更の採用可能性』の論点は、それでもやはり、極めて重要です。その変更は、インターネットが新しいアプリケーション、プロトコルおよび機能をサポートするように発展する能力を完全にはブロックしてしまうことなく、正規でないセキュリティの関心事を防ぐことにあります。
RFC 793 には、「TCP ヘッダー中の Reserved フィールドは、将来の利用のために確保されており、ゼロでなければならない」と書かれています。この文書の他の部分と、より整合するように書き直すならば、「Reserved
フィールドは、将来の標準化活動によって規定されない限り、送信されたとき、ゼロである必要があり、受信されたとき、無視される必要がある」ということであったはずです。しかし、RFC
793 中の記述は、上記の章において説明したような、非ゼロの Reserved フィールドをもつ TCP パケットに応じた Reset の送信を許容していません。
「アプリケーションは、ファイアウォールが在る場合でも正しく動作し続けなければならない。これは、下記の透過性ルールに翻訳されます。： ファイアウォールや、あらゆる関連するトンネリング設備（あるいはアクセス交渉設備）の導入は、
そのファイアウォールが無かった場合、動作する正規かつ標準準拠の用法の意図しない失敗をもたらしてはならない（MUST NOT）。」
「この要求に対する必要不可欠な類推は、『このような失敗が実際に起きたとき、その問題に対応することは、ファイアウォールや関連するソフトウェアの責任となる』ということである。：
既存の標準プロトコルの実装の変更も、そのプロトコル自体の変更も、必須であってはならない（MUST NOT）。」
「『この要件は、正規のプロトコルの用法と、いわれのない失敗にのみ適用されること』に注意。（ファイアウォールは、（試みられているアクセ宇が標準準拠であるか否かにかかわらず）サイトが不正と見なす、あらゆる種類のアクセスをブロックすることができます。）」
我々は、「RFC 2979 は、情報提供 RFC であること」を指摘しておきます。インターネット標準化過程についての RFC 2026 は、その
4.2.2 節において、下記のことを述べています。： 「情報提供（Informational）の規定は、インターネットコミュニティへの一般的な情報提供のために発行されており、インターネットコミュニティの合意事項もしくは推奨事項を表現するものではありません
ファイアウォールやホストには、混雑制御メカニズムとしての SYN パケットに応じて Reset を送るものがあります。例えば、ファイアウォールが待ち受けている（listen）キュー（queue）が満杯のときです。これらの
Reset は、TCP Reserved フィールドの中身を考慮せずに送られます。おそらく、混雑制御メカニズムとしての Reset の利用に応じて、いくつかの普及している
我々は、「TCP Reset が混雑制御メカニズムとしては使われないこと」を推奨します。なぜなら、これは、Reset メッセージの処理に過負荷をかけ、必然的に
TCP 実装による Reset に応じた、より攻撃的なふるまいをもたらすからです。我々は、「単に、SYN パケットを棄却することが、混雑に対する最も効果的な応答であること」を示唆します。TCP
の送信者は、RTO（Retransmission Timeout： 再転送タイムアウト）についてのデフォルト値を使って、 各再転送後にその再転送タイマーを戻して、その
「入り方向のセグメントがセキュリティのレベル、もしくはコンパートメントをもつ場合、もしくは、必ずしもレベルやコンパートメントに合致しない「優先権（precedence）」をもち、優先権がそのコネクションを要求した場合、Reset
IP セキュリティオプションを指します。これが書かれたとき、これは、RFC 793 中に書かれている「Reset は、外観上、現在のコネクションとして意図されていないセグメントが到達するときにのみ送られる必要がある」というガイドラインと整合していました。
は、優位なフィールドが変更されたとき、Reset の送信によって提起された具体的な問題を検討しています。RFC 2873（現在は、Proposed
Standard）は、「TCP は、すべての受信したセグメントの優先権を無視しなければならず、その優先権（precedence）フィールドにおける変更に応じて
Reset を送ってはならない」と規定しています。我々は、「この論点について、非ゼロの TCP Reserved フィールドをもつセグメントに応じた
「TCP は、あらゆるセグメント中の TCP オプションを受信することができなければならない（MUST）。TCP は、オプションとして、長さ（length）フィールドをもつことと想定して、実装していない、いかなる
TCP オプションもエラーとすることなく、無視しなければならない（MUST）。（将来規定されるすべての TCP オプションは、長さ（length）フィールドをもつ。）TCP
は、クラッシュすることなく、不正なオプション長（例： ゼロ）を扱うことに備えなければならない（MUST）。示唆される手順は、そのコネクションをリセットし、その理由を記録することである。」
これは、理にかなっています。なぜなら、TCP 受信者は、不正なオプション長の TCP オプションをもつセグメント上のデータ の Reset を解釈できないからです。繰り返しになりますが、我々は、「この論点は、非ゼロの
TCP Reserved フィールドをもつセグメントに応じて Reset の送信を決して許容しないこと」を明確化するために、これをここで検討します。
インターネットは、「エンド to エンド」の混雑制御に基づいており、歴史的に、インターネットは、ルーターが混雑をエンドノードに対して示すための唯一の手法として、パケット棄却を使ってきました。ECN
は、ルーターがパケットを棄却する代わりに、混雑についてエンドノードに知らせるための IP パケットヘッダー中のビットをセットできるようにするために、IP
アーキテクチャに最近、追加されたものです。ECN は、そのトランスポートのエンドノード間の協調を要求します。
の利用をサポートするようにアップグレードされていること」と、「両端のノードが、ECN をこの特定の TCP コネクションにおいて使うことに合意すること」を要求します。この
TCP の両端ノード間の ECN サポートについての交渉は、TCP ヘッダー中の Reserved フィールド から割り当てられた 2 つのフラグを使います
TCP ヘッダー中の 2 つの ECN フラグは、TCP ヘッダーの Reserved フィールド中の最後の 2 つのビットによって規定されています。TCP
パケット（ECE と CWR のフラグがセットされた TCP SYN パケット）」を送ります。他端の TCP ホストが ECN をこのコネクションについて使うことを望む場合、これは、「ECN-setup
SYN-ACK パケット（ECE フラグがセットされており、CWR フラグがセットされていない TCP SYN パケット）」を送ります。そのようにしないと、他端にある
TCP ホストは、ECE フラグも CWR フラグもセットされていない SYN-ACK パケットを返します。
フィールド中のそれらのフラグを無視し、応答として、プレインな SYN-ACK パケットを送信することが期待されます。しかし、インターネットには、ECN-setup
SYN パケットに対して Reset で応答する壊れたファイアウォールやロードバランサーがあります。ECN 対応可能なエンドノードの配備に従うと、広く「ECN
対応可能なホストは、数多くの Web サイトにアクセスできない [Kelson00]」という不満がありました。これは、Linux コミュニティによって調査されてきたことであり、データについては、2000年
Linux Today" [Cou01] にある読み物において検討されています。問題の機器のいくつかは、識別されており、ある
Web ページ [FIXES] には、非準拠製品の一覧と、そのベンダーによって投稿された修正コードが掲げられています。2002年
の Reserved フィールド中のフラグを使っているパケットをブロックするソフトウェアの導入は、後でそのソフトウェアをアンインストールするより、かなり楽です
壊れた機器に直面したとき、接続性を維持管理するための対処策は、[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 パケットを再転送する可能性があります。
対処策は、ECN 対応可能ホストが SYN パケットに応じて受信した最初の正規の Reset に正しく対応しないことをもたらします。
対処策は、最初の SYN もしくは SYN-ACK パケットがネットワーク内で棄却された場合、ECN を不能にすることによって、壊れた機器が無い環境において
多くの場合、ECN-setup SYN パケットを棄却する壊れた機器があるときの対処策は、その遠隔サーバーとの接続性が確立するまでに 6 秒以上の遅延をもたらします。この壊れた機器の面倒をみることによる対処策は、暗黙の内に、この遅延と、この遅延をもたらす壊れた機器の両方を受容することとして、判定されてきました。
Reset に応じて細工された SYN パケットを再送するという対処策に不可避な結末は、さらに
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 サーバー、あるいは、ファイアウォールの存在は、インターネットの将来の発展を制限するインターネットにおける機能の一例にすぎません。これらの小さな制約事項がすべて合わさった影響は、インターネットアーキテクチャの開発に対する相当な障害をもたらします。
トランスポートプロトコルの設計者にとっての試練は、「トランスポートプロトコルは、ネットワーク中のファイアウォール、ノーマライザー（Normalizer）および他の中間ボックスの未知かつ任意に見える活動から自らを防護する必要があること」です。現時点において、TCP
について、これは、Reset が ECN-setup SYN パケットに応じて受信されたとき、非 ECN-setup SYN を送ることを意味します。トランスポートプロトコル側における防護機能は、データ
トラフィックにおいて利用する前における、それらのフラグを使ってパケットをブロックしてしまう中間ボックス対策としての SYN パケット中の Reserved
フラグの利用を含む可能性があります。「トランスポートプロトコルは、そのコネクションの存続期間において、パス上の中間ボックスからの干渉についてチェックするために、さらなるチェックも追加しなければならないこと」は、ありえます。
ECN についての標準文書である RFC 3168 には、「ネットワーク内における ECN フィールドについての変更の可能性」についての 18章に広範な検討がありますが、TCP
「本書は、ネットワーク中におけるトランスポートヘッダーの変更によってもららされる潜在的な危険を考慮しません。我々は、『IPsec が使われているとき、そのトランスポートヘッダーは、トンネルモードとトランスポートモード
（下記 6.2 節 において検討されているような）ファイアウォールのよるネットワーク中のトランスポートレベルのヘッダーについての今般の変更によって、将来のプロトコル設計者は、もはや、ネットワーク内におけるトランスポートヘッダーに対する変更の影響の可能性を無視する余裕をもたない可能性があります。
トランスポートプロトコルは、また、中間ボックスが、この形態の ICMP の「宛先到達不能（Destination Unreachable）」メッセージを「そのパケットは、許可されていない機能
[RFC1812] を使っていること」を示すために使い始めた場合、ICMP コード：「通信は運用管理的に禁止されている（Communication
どこかの中間ボックスが、パケットがその中間ボックスによって許可されていない機能を使うことを理由に、いくつかのパケットを棄却しようとしているとき、「このようなしょりがある場合、どのように、中間ボックスは、この処理についての理由をエンドノード宛てに通信する必要があるか？」という、より大きな論点が残ります。別の文書にある、より深い考察からのひとつの示唆は、「ファイアウォールは、『通信は運用管理的に禁止されている（Communication
我々は、「これは、いくつかの理由で、理想的な解決策ではないこと」を告知します。最初に、その逆に辿る経路上の中間ボックスは、これらの ICMP メッセージをブロックする可能性があります。2
番目に、ファイアウォール運用者には、明示的な通信に反対する者がいます。なぜなら、セキュリティポリシーについて、あまりに多くの情報を明かすからです。3
番目に、このような ICMP メッセージに対するトランスポートプロトコルのレスポンスは、まだ規定されていません。
しかし、ICMP の「運用管理的に禁止（Administratively Prohibited）」のメッセージは、明示的な通信を使うことを望むファイアウォールについて、合理的な追加である可能性があります。繰り返しになりますが、別の文書において探求されるべきひとつの可能性は、ICMP「運用管理的に禁止（Administratively
Prohibited）」メッセージが追加的な情報をエンドホスト宛に運ぶように修正されることです。
我々は、「本書は、完全なトランスポートプロトコルをブロックする中間ボックスを考慮しないこと」を指摘します。我々は、「本書は、firewalled-off
TCP ポート宛の TCP SYN パケットに応じて Reset を送信するファイアウォールに対応していないこと」も指摘します。このような Reset
の利用は、TCP Reset の趣旨と整合するように見えます。本書は、そのトランスポートプロトコルの他のパケットの後に、その中間ボックスが変更されないとき、トランスポートプロトコル中の特定のパケットをブロックする中間ボックスによって引き起こされる問題のみを検討しています。我々の面倒な事態は、「ひとたび特定の機能をブロックするために、あるメカニズムがファイアウォールにインストールされると、ネットワーク運用管理者が
そのブロックを『アンインストール』するために相当な労力を要する可能性があること」です。「ファイアウォールにおける拡張可能な設定は、全体的に、より少ない痛みで将来のインシデントから復旧させる可能性があること」が示唆されてきました。なぜなら、繰り返しになりますが、本書は、ファイアウォール、より柔軟なファイアウォールの柔軟性の論点、および、別の文書に書かれる「付随する可能性があるセキュリティリスク」についての、より一般的な論点に対応していないからです。
TCP ヘッダー中の予約されたビットを使う TCP パケットを棄却するようにしているファイアウォールがあるとき、ひとつの疑問は、「TCP コネクションが
TCP 送信者において、その転送のタイムアウトを待つのに無駄に資源を浪費することを防ぐために、ファイアウォールは、Reset も送る必要があるか否か？」です。我々は、「ファイアウォールが
TCP パケットを棄却しなければならないのにもかかわらず、TCP Reset を送ることは、不適切である」と主張します。禁止された機能に応じて TCP
一例として、2.3 節 において既に、「ファイアウォールには、混雑制御メカニズムとしての TCP SYN パケットに応じて
Rreset を送るものがあること」を見てきました。おそらく、これに応じて、（もしくは、おそらく、
ものがあります。標準に準拠した他の TCP 実装は、Reset を受信した後、SYN パケットを再送しません。
TCP パケットに応答するという当初の目的に使われるとき、 その Reset の有効性を低下させます。
からであるか、あるいは、パケットは、以前の TCP コネクションから受信されたからであり、TCP 実装（あるいは、より正しくは、TCP 実装者）は、今や、
という上記の動機づけ要因に加えて、その TCP Reset は、混雑ではなく、禁止された機能に起因する可能性があり、それゆえ、その TCP 実装は、
異なる形態の SYN パケットを再送する可能性があります。このような TCP Reset の意味の頻繁な変更は、
しかし、ファイアウォールが、Reset を送信するか、単にそのパケットを棄却するかを選択しなければならない場合、我々は、「単にパケットを棄却することは、エンドホストに対策を採用する動機を与える観点から、被害が少ない」と主張します。「Reset
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 エンド」の混雑制御を破壊するという意図しなかった結末をもたらす可能性があります。これらの可能性ある相互作用の詳細は、本書にとっては重要ではないので、補遺
他の 4 つのビットについての将来の利用」の両方についての我々の結論は、「あるプロトコルに追加された新しい機能の利用をブロックできることがファイアウォールについて要求される場合、これは、ファイアウォールコミュニティとプロトコル設計者の協働によって、初期設計段階において、もっともうまく対応される」ということです。
我々の結論は、「単にそのパケットが TCP Reserved フィールド中のフラグを使っているからといって、TCP SYN パケットに Reset
で応答することは、ファイアウォール、ロードバランサーもしくは Web サーバーについての現在の標準に準拠していない」ということです。より具体的には、これは、単に
ECE と CWR のフラグが IP ヘッダー中にセットされているからといって、TCP SYN パケットに Reset で応答することと整合しません。我々は、ベンダーに、あらゆる非整合なコードについて、入手可能な修正コードを作成することを促し、そして、ISP
やシステム運用管理者に対して、彼らの Web サーバーやファイアウォールに、これらの修正コードを採用することを促す可能性があります。
我々は、「これは、TCP Reserved フィールド中のフラグを使うパケットを勝手に棄却する中間ボックスについてのあらゆる標準を侵害する」と非難しているわけではなく、我々は、「エンドノードに、これらの活動についての理由を通知するための明確な手法を伴わない、この種のふるまいは、TCP
の開発に対して、顕著な障害をもたらす可能性があること」を主張しているのです。さらなる作業が、インターネットプロトコルの慎重な進化を許容すると同時に、セキュリティを提供するという衝突する利害を和解させるために、明らかに必要とされます。
本書は、多くの人々による検討と活動の結果であるので、私は、ここにすべてを反映して謝辞を述べることを試みます。私の、具体的な感謝は、本書についてフィードバックしてくれた
Olsson に感謝します。私は、本書の以前のドラフトについてフィードバックしてくれた（概ね合意しないないようでしたが）"Firewall
Venkat Venkatsubra を含む数多くの人々との電子メールによる検討は、インターネットにおける非準拠機器によって提起された論点に対応するものでした。非準拠機器とは、TCP
SYN パケットに ECE と CWR のフラグをセットすることで応答しないものです。我々は、TCP 初期化手順について検討してくださった Mark
TCP 中の Reserved フラグを使うことの一般的なリスクのひとつは、問題となるホストの設定についての追加的情報を提供することのリスクです。しかし、TCP
ICMP 宛先不当着（Destination Unreachable）メッセージについての他のすべての考慮事項は、別の文書において検討されます。
従来のファイアウォールの関心は、システムに対する認可されていないアクセスを防ぐこと、エンドユーザ端末を破壊することから DoS 攻撃や他の攻撃を防ぐこと、および、「エンドシステムをバグが多いコードから防護すること」にありました。我々は、TCP
ヘッダー中の Reserved フラグの利用から報告されているセキュリティ脆弱性 [SFO01] を認識しています。パケットフィルタは、確立されたコネクションにおいてパケットを単に通過させるのではなく、そのパケットの
Reserved フィールド中に ECE フラグがセットされている場合、確立されたコネクション中以外で、パケットを転送させることができます。
残念ながら、見当違いなセキュリティの関心事（の存在）は、本書の最初に記述した問題の理由のひとつです。2000年
ポートスキャン用ツールである Queso について記述しており、下記のことが書かれています。：
[これらの 2 つの Reserved ビットと SYN ビット] が TCP ヘッダーの 13 番目のバイトにセットされている場合、あなたは、『誰かが、あなたのネットワークについて、悪意をもっていること』を知ります。」TBIT
の Web ページ上に文書化されているように、TCP ヘッダー中の 2 つの ECN 関連 Reserved フラグを使っている SYN をブロックする中間ボックスは、TCP
ひとつの教訓は、「誰でも、単に、公衆が入手可能なポートスキャンを行うツールにある機能を使うことによって、新しい
TCP 機能を効果的に『攻撃』できること」のようです。それゆえ、すべての種類の中間ボックスが、その機能の利用をブロックするようにします。
A からホスト B 宛ての最初の SYN パケットにおいてゼロ化されていないが、ホスト B から ホスト A 宛の応答する SYN/ACK
パケットにおいてゼロ化されている場合、その結末は、このコネクションについて、『エンド to エンド』の混雑制御を破壊するものである可能性があること」を示します。
は、下記の図 3 のように、ネットワーク内でファイアウォールによって、非-ECN-setup SYN/ACK に変更される」と想定します。RFC 3168
は、「結局、ACK パケットは、SYN/ACK パケットにおいて受信した TCP フラグに echo する必要がある」とは規定していません。なぜなら、設計者にしてみれば、「これらのフラグは、そのネットワーク中で変更される」ようなことは無かったからです。
SYN/ACK パケットを受信してきましたし、データパケット上に、ECT をセットしてはなりません。しかし、ホスト B は、「ホスト A が、非 ECN-setup
SYN/ACK パケットを受信したこと」を知りませんし、ホスト B は、ECT をデータパケットにセットする可能性があります。RFC 3168 は、ホスト
A に、ホスト B から受信した ECT と CE コードポイントが IP ヘッダー中にセットされたデータパケットに対して正しく応答することを要求していません。それゆえ、そのデータ送信者（ホスト
B）は、そのネットワークに起きている混雑について知らされない可能性があり、それゆえ、「エンド to エンド」の混雑制御を侵害します。
パケットにおいても、SYN/ACK パケットにおいてもゼロ化されていないが、そのファイアウォールが 、その TCP コネクション中の後のパケットにおいて、これらのフラグをゼロ化する場合、これは、このコネクションについての「エンド
to エンド」の混雑制御を破壊する」という意図しない結末になる可能性もあることを示します。図 4 は、このシナリオを示します。
and 両端のノードは、ECN を使うことができるとともに、IP ヘッダーにおいて ECN フィールド内に ECT フラグをセットすることができます。しかし、そのファイアウォールが
されたとき、追加的な複雑さが発生します。なぜなら、これは、TCP Reserved フィールドを使って、TCP データ送信者宛の TCP データの受信者からのフィードバックのための追加的なフラグの仕様を含む可能性があるからです。ECN
nonce についての主要な動機は、「ネットワーク要素は、CE コードポイントを消去していないこと」と、「データ受信者は、パケットの受信を CE コードポイントのセットで送信者宛に正しく報告していること」を検証するために、そのデータ送信者にメカニズムを許容することです。
|
