Network Working Group S. Floyd
Request for Comments: 3360 ICIR
BCP: 60 August 2002
Category: Best Current Practice
Inappropriate TCP Resets Considered Harmful
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document is being written because there are a number of firewalls in the Internet that inappropriately reset a TCP connection upon receiving certain TCP SYN packets, in particular, packets with flags set in the Reserved field of the TCP header. In this document we argue that this practice is not conformant with TCP standards, and is an inappropriate overloading of the semantics of the TCP reset. We also consider the longer-term consequences of this and similar actions as obstacles to the evolution of the Internet infrastructure.
不適切特定のTCP SYNパケット、特に、TCPヘッダの予備フィールドに設定されたフラグを持つパケットを受信すると、TCP接続をリセットし、インターネットにファイアウォールの数があるため、この文書では、書き込まれています。この文書では、このような行為は、TCP標準に準拠していない、とTCPリセットの意味論の不適切な過負荷であると主張しています。また、長期的な本の帰結とインターネットインフラの進化への障害と同様の措置を検討してください。
TCP uses the RST (Reset) bit in the TCP header to reset a TCP connection. Resets are appropriately sent in response to a connection request to a nonexistent connection, for example. The TCP receiver of the reset aborts the TCP connection, and notifies the application [RFC793, RFC1122, Ste94].
TCPは、TCP接続をリセットするために、TCPヘッダにRST（リセット）ビットを使用します。リセットは適切例えば、存在しない接続に接続要求に応答して送信されます。リセットのTCP受信機は、TCP接続を中止し、アプリケーション[RFC793、RFC1122、Ste94]を通知します。
Unfortunately, a number of firewalls and load-balancers in the current Internet send a reset in response to a TCP SYN packet that use flags from the Reserved field in the TCP header. Section 3 below discusses the specific example of firewalls that send resets in response to TCP SYN packets from ECN-capable hosts.
残念ながら、現在のインターネットにファイアウォールやロードバランサの数は、TCPヘッダ内の予約フィールドからのフラグを使用してTCP SYNパケットに応答してリセットを送信します。以下のセクション3は、ECN-できるホストからのTCP SYNパケットに応答してリセットを送信ファイアウォールの具体例を説明します。
This document is being written to inform administrators of web servers and firewalls of this problem, in an effort to encourage the deployment of bug-fixes [FIXES]. A second purpose of this document is to consider the longer-term consequences of such middlebox behavior on the more general evolution of protocols in the Internet.
この文書では、バグフィックス[解決]の展開を奨励するための努力で、Webサーバと、この問題のファイアウォールの管理者に知らせるために書かれています。このドキュメントの第二の目的は、インターネットにおけるプロトコルのより一般的な進化に、このようなミドル行動の長期的な影響を考慮することです。
This section gives a brief history of the use of the TCP reset in the TCP standards, and argues that sending a reset in response to a SYN packet that uses bits from the Reserved field of the TCP header is non-compliant behavior.
このセクションでは、TCP基準のTCPリセットの使用の簡単な歴史を与え、およびTCPヘッダーの予約フィールドからのビットを使用してSYNパケットに応答してリセットを送信することは非準拠の動作であると主張しています。
RFC 793 contained the original specification of TCP in September, 1981 [RFC793]. This document defined the RST bit in the TCP header, and explained that reset was devised to prevent old duplicate connection initiations from causing confusion in TCP's three-way handshake. The reset is also used when a host receives data for a TCP connection that no longer exists.
RFC 793 [RFC793]、1981年9月にTCPの元の仕様を含んでいました。このドキュメントでは、TCPヘッダにRSTビットを定義し、リセットがTCPの3ウェイハンドシェイクの混乱を引き起こしてから、古い重複した接続イニシエーションを防ぐために考案されたと説明しました。ホストはもはや存在していることをTCP接続のためのデータを受信したときにリセットにも使用されています。
RFC 793 states the following, in Section 5:
RFC 793は、第5節では、次のように述べています：
"As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case."
「一般的なルールとして、（RST）をリセットセグメントは明らかに、現在の接続のために意図されていない到着するたびに送信されなければならない。これが事実であることが明らかでない場合にリセットが送信されてはなりません。」
RFC 1122 "amends, corrects, and supplements" RFC 793. RFC 1122 says nothing specific about sending resets, or not sending resets, in response to flags in the TCP Reserved field.
RFC 1122「償い、修正、およびサプリメント」RFC 793 RFC 1122は、リセットを送信に関する特定の何も言わない、またはTCP予約済みフィールドのフラグに応じて、リセットを送信していません。
Thus, there is nothing in RFC 793 or RFC 1122 that suggests that it is acceptable to send a reset simply because a SYN packet uses Reserved flags in the TCP header, and RFC 793 explicitly forbids sending a reset for this reason.
このように、SYNパケットはTCPヘッダに予約済みのフラグを使用して、RFC 793は、明示的にこのような理由のためにリセットを送信禁じているので、単にリセットを送信するために許容可能であることを示唆しているRFC 793またはRFC 1122には何もありません。
RFC 793 and RFC 1122 both include Jon Postel's famous robustness principle, also from RFC 791: "Be liberal in what you accept, and conservative in what you send." RFC 1122 reiterates that this robustness principle "is particularly important in the Internet layer, where one misbehaving host can deny Internet service to many other hosts." The discussion of the robustness principle in RFC 1122 also states that "adaptability to change must be designed into all levels of Internet host software". The principle "be liberal in what you accept" doesn't carry over in a clear way (if at all) to the world of firewalls, but the issue of "adaptability to change" is crucial nevertheless. The challenge is to protect legitimate security interests without completely blocking the ability of the Internet to evolve to support new applications, protocols, and functionality.
RFC 793とRFC 1122の両方はまた、RFC 791から、ジョン・ポステルの有名な堅牢性の原則が含まれています。「あなたが受け入れるものにリベラル、とあなたが送る何で保守的です。」 RFC 1122は、この堅牢性の原則「とは、一台の誤動作ホストは、他の多くのホストにインターネットサービスを拒否することができ、インターネット層、特に重要である。」ことを改めて表明しますRFC 1122で堅牢性の原則の議論も、「変化に対する適応性は、インターネットホストソフトウェアのすべてのレベルに設計されなければならない」と述べています。原則は、ファイアウォールの世界に（すべてであれば）明確な形で引き継がれません「あなたが受け入れるものにリベラルこと」が、「変更する適応性」の問題は、それにもかかわらず、非常に重要です。課題は、全く新しいアプリケーション、プロトコル、および機能をサポートするために進化するインターネットの能力をブロックすることなく、正当な安全保障上の利益を保護することです。
RFC 793 says that the Reserved field in the TCP header is reserved for future use, and must be zero. A rephrasing more consistent with the rest of the document would have been to say that the Reserved field should be zero when sent and ignored when received, unless specified otherwise by future standards actions. However, the phrasing in RFC 793 does not permit sending resets in response to TCP packets with a non-zero Reserved field, as is explained in the section above.
RFC 793は、TCPヘッダー内の予約フィールドは将来の使用のために予約され、ゼロでなければならないと述べています。文書の残りの部分とより一致言い換えは、送受信されたときに、将来の標準アクションで特に指定がない限り、無視されたときに予約済みフィールドがゼロであるべきと言うことだったでしょう。しかし、RFC 793でフレーズは、上記のセクションで説明されたように、非ゼロのReservedフィールドを持つTCPパケットに応答してリセットを送信可能にしません。
RFC 2979 on the Behavior of and Requirements for Internet Firewalls [RFC2979], an Informational RFC, contains the following:
インターネットファイアウォール[RFC2979]、情報RFCのための行動と要件のRFC 2979には、次のものが含まれています。
"Applications have to continue to work properly in the presence of firewalls. This translates into the following transparency rule: The introduction of a firewall and any associated tunneling or access negotiation facilities MUST NOT cause unintended failures of legitimate and standards-compliant usage that would work were the firewall not present."
。「アプリケーションは、これは以下の透明性規則に変換ファイアウォールの存在下で適切に動作し続けることがあります：ファイアウォールの導入および関連するトンネリングまたはアクセス交渉設備が働くだろう正当かつ標準準拠の用法の意図しない障害を引き起こしてはなりませんファイアウォールは存在しませんでした。」
"A necessary corollary to this requirement is that when such failures do occur it is incumbent on the firewall and associated software to address the problem: Changes to either implementations of existing standard protocols or the protocols themselves MUST NOT be necessary."
「この要件に必要な帰結は、このような障害が発生したとき、問題に対処するために、ファイアウォール上の現職および関連ソフトウェアであるということである：既存の標準プロトコルまたはプロトコルそのもののいずれかの実装への変更が必要にならない（MUST NOT）」
"Note that this requirement only applies to legitimate protocol usage and gratuitous failures -- a firewall is entitled to block any sort of access that a site deems illegitimate, regardless of whether or not the attempted access is standards-compliant."
「この要件は唯一の合法的なプロトコルの使用や無償の障害に適用されることに注意してください - 。ファイアウォールはサイトは関係なく、試みられたアクセスが標準規格に準拠しているかどうかの、非合法とみなすことのアクセスの任意の並べ替えを阻止する権利があります」
We would note that RFC 2979 is an Informational RFC. RFC 2026 on Internet Standards Process says the following in Section 4.2.2: "An `Informational' specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation" [RFC2026].
私たちは、RFC 2979が情報のRFCであることに注意します。インターネット標準化過程のRFC 2026は、4.2.2項に、次の言う：「`情報」仕様はインターネットコミュニティの一般的な情報は公開され、およびインターネットコミュニティコンセンサスまたは推奨を示すものではありません」[RFC2026]。
Some firewalls and hosts send resets in response to SYN packets as a congestion control mechanism, for example, when their listen queues are full. These resets are sent without regard to the contents of the TCP Reserved field. Possibly in response to the use of resets as a congestion control mechanism, several popular TCP implementations immediately resend a SYN packet in response to a reset, up to four times.
一部のファイアウォールおよびホストは、耳を傾け、キューが一杯になったときに、例えば、輻輳制御機構としてSYNパケットに応じてResetを送ります。これらのリセットは、TCP予約フィールドの内容に関係なく送信されます。おそらく輻輳制御機構としてのリセットの使用に応じて、いくつかの人気のTCP実装は、すぐに4回まで、リセットに応じて、SYNパケットを再送します。
We would recommend that the TCP reset not be used as a congestion control mechanism, because this overloads the semantics of the reset message, and inevitably leads to more aggressive behavior from TCP implementations in response to a reset. We would suggest that simply dropping the SYN packet is the most effective response to congestion. The TCP sender will retransmit the SYN packet, using the default value for the Retransmission Timeout (RTO), backing-off the retransmit timer after each retransmit.
私たちは、これがリセットメッセージの意味をオーバーロード、そして必然的にリセットに応じて、TCP実装から、より攻撃的な行動につながるため、TCPは、輻輳制御機構として使用することはできませんリセットすることをお勧めします。私たちは、単にSYNパケットをドロップすると、渋滞に最も効果的な対応であることを示唆しています。 TCPの送信者は、バックオフの各再送後の再送信タイマーを、再送信タイムアウト（RTO）のデフォルト値を使用して、SYNパケットを再送します。
RFC 793 includes the following in Section 5:
RFC 793は、第5節では、以下が含まれます。
"If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection, a reset is sent and connection goes to the CLOSED state."
「着信セグメントが正確にレベル、コンパートメント、および接続のための要求された優先順位と一致しないセキュリティレベル、または区画、または優先順位を有する場合、リセットが送信され、接続が閉じた状態に移行されます。」
The "precedence" refers to the (old) Precedence field in the (old) ToS field in the IP header. The "security" and "compartment" refer to the obsolete IP Security option. When it was written, this was consistent with the guideline elsewhere in RFC 793 that resets should only be sent when a segment arrives which apparently is not intended for the current connection.
「優先順位」は、IPヘッダ内の（古い）ToSフィールドに（古い）Precedenceフィールドを指します。 「セキュリティ」と「コンパートメント」廃止されたIP Securityオプションを参照してください。それが書かれたとき、これはセグメントが明らかに現在の接続のために意図されていない到着したときにのみ送信されるべきリセットし他の場所RFC 793で指針と一致していました。
RFC 2873 on "TCP Processing of the IPv4 Precedence Field" discusses specific problems raised by the sending of resets when the precedence field has changed [RFC2873]. RFC 2873, currently a Proposed Standard, specifies that TCP must ignore the precedence of all received segments, and must not send a reset in response to changes in the precedence field. We discuss this here to clarify that this issue never permitted the sending of a reset in response to a segment with a non-zero TCP Reserved field.
「IPv4の優先順位フィールドのTCP処理」のRFC 2873が優先フィールドは、[RFC2873]を変更されたときにリセットを送信することにより提起特定の問題について説明します。 RFC 2873は、現在提案されている標準は、TCPが受信されたすべてのセグメントの優先順位を無視しなければならない、とprecedenceフィールドの変化に応じて、リセットを送信してはならないことを指定します。私たちは、この問題は、非ゼロのTCP予約フィールドを持つセグメントに応じて、リセットの送信を許可しないことを明確にするために、ここでこれを議論します。
RFC 1122 says the following in Section 4.2.2.5 about TCP options [RFC1122]:
RFC 1122は、TCPオプション[RFC1122]についてのセクション4.2.2.5に次のように述べています：
"A TCP MUST be able to receive a TCP option in any segment. A TCP MUST ignore without error any TCP option it does not implement, assuming that the option has a length field (all TCP options defined in the future will have length fields). TCP MUST be prepared to handle an illegal option length (e.g., zero) without crashing; a suggested procedure is to reset the connection and log the reason."
A TCPは、任意のセグメントでのTCPオプションを受け取ることができなければならない」。A TCPは、（将来的に定義されているすべてのTCPオプションは、長さフィールドを持つことになります）オプションは、長さフィールドを持っていると仮定して、エラーなしで、それは実装していない任意のTCPオプションを無視しなければなりません。TCPは、クラッシュすることなく、不正なオプション長（例えば、ゼロ）を処理するために準備しなければなりません。提案手法は、接続をリセットし、その理由を記録することです「。
This makes sense, as a TCP receiver is unable to interpret the rest of the data on a segment that has a TCP option with an illegal option length. Again, we discuss this here to clarify that this issue never permitted the sending of a reset in response to a segment with a non-zero TCP Reserved field.
TCP受信機が不正なオプション長とのTCPオプションを持っているセグメント上の残りのデータを解釈することができないので、これは、理にかなっています。繰り返しますが、私たちは、この問題は、非ゼロのTCP予約フィールドを持つセグメントに応じて、リセットの送信を許可しないことを明確にするために、ここでこれを議論します。
This section has a brief explanation of ECN (Explicit Congestion Notification) in general, and the ECN-setup SYN packet in particular.
このセクションでは、一般にECN（明示的輻輳通知）の簡単な説明、特に、ECN-セットアップSYNパケットを有しています。
The Internet is based on end-to-end congestion control, and historically the Internet has used packet drops as the only method for routers to indicate congestion to the end nodes. ECN is a recent addition to the IP architecture to allow routers to set a bit in the IP packet header to inform end-nodes of congestion, instead of dropping the packet. ECN requires the cooperation of the transport end-nodes.
インターネットは、エンドツーエンドの輻輳制御に基づいており、歴史的にインターネットは、パケットがエンドノードに輻輳を示すためにルータのための唯一の方法として低下使用してきました。 ECNは、ルータの代わりにパケットを滴下する、輻輳のエンドノードに知らせるために、IPパケットヘッダ内のビットを設定することを可能にするIPアーキテクチャに最近追加されました。 ECNは、トランスポート・エンドノードの協力が必要です。
The ECN specification, RFC 2481, was an Experimental RFC from January 1999 until June 2001, when a revised document [RFC3168] was approved as Proposed Standard. More information about ECN is available from the ECN Web Page [ECN].
ECN仕様、RFC 2481は、1999年1月からの改訂文書[RFC3168]が提案されている標準として承認されました2001年6月まで実験的RFCました。 ECNについての詳しい情報は、ECNのWebページ[ECN]から入手可能です。
The use of ECN with TCP requires that both TCP end-nodes have been upgraded to support the use of ECN, and that both end-nodes agree to use ECN with this particular TCP connection. This negotiation of ECN support between the two TCP end-nodes uses two flags that have been allocated from the Reserved field in the TCP header [RFC2481].
TCPでのECNの使用は、両方のTCPエンドノードはECNの使用をサポートするようにアップグレードされている必要があり、両方のエンドノードは、この特定のTCP接続でECNを使用することに同意していること。 2つのTCPエンドノード間のECNサポートのこのネゴシエーションは、TCPヘッダ[RFC2481]でのReservedフィールドから割り当てられた2つのフラグを使用します。
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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: The previous definition of bytes 13 and 14 of the TCP header.
図1：バイト13とTCPヘッダの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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: The current definition of bytes 13 and 14 of the TCP Header, from RFC 3168.
図2：バイト13とTCPヘッダの14の現在の定義は、RFC 3168から。
The two ECN flags in the TCP header are defined from the last two bits in the Reserved field of the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag (ECE), and Bit 8 is designated as the Congestion Window Reduced (CWR) flag. To negotiate ECN usage, the TCP sender sends an "ECN-setup SYN packet", a TCP SYN packet with the ECE and CWR flags set. If the TCP host at the other end wishes to use ECN for this connection, then it sends an "ECN-setup SYN-ACK packet", a TCP SYN packet with the ECE flag set and the CWR flag not set. Otherwise, the TCP host at the other end returns a SYN-ACK packet with neither the ECE nor the CWR flag set.
TCPヘッダ内の2つのECNフラグは、TCPヘッダのReservedフィールドの最後の2ビットから定義されます。 TCPヘッダのReservedフィールドのビット9は、ECN-エコーフラグ（ECE）として指定され、ビット8を低減輻輳ウィンドウ（CWR）フラグとして指定されます。 ECNの使用を交渉するために、TCPの送信者は、「ECN-セットアップSYNパケット」、設定ECEとCWRフラグを持つTCP SYNパケットを送信します。もう一方の端のTCPホストがこの接続のためにECNを使用したい場合は、それは、「ECN-セットアップSYN-ACKパケット」、ECEフラグセットと設定されていないCWRフラグをTCP SYNパケットを送信します。それ以外の場合は、もう一方の端のTCPホストがECEもCWRフラグセットでもないとSYN-ACKパケットを返します。
So now back to TCP resets. When a TCP host negotiating ECN sends an ECN-setup SYN packet, an old TCP implementation is expected to ignore those flags in the Reserved field, and to send a plain SYN-ACK packet in response. However, there are some broken firewalls and load-balancers in the Internet that instead respond to an ECN-setup SYN packet with a reset. Following the deployment of ECN-enabled end nodes, there were widespread complaints that ECN-capable hosts could not access a number of websites [Kelson00]. This has been investigated by the Linux community, and by the TBIT project [TBIT] in data taken from September, 2000, up to March, 2002, and has been discussed in an article in Enterprise Linux Today [Cou01]. Some of the offending equipment has been identified, and a web page [FIXES] contains a list of non-compliant products and the fixes posted by the vendors. In March 2002, six months after ECN was approved as Proposed Standard, ECN-setup SYN packets were answered by a reset from 203 of the 12,364 web sites tested, and ECN-setup SYN packets were dropped for 420 of the web sites. Installing software that blocks packets using flags in TCP's Reserved field is considerably easier than uninstalling that software later on.
だから今バックTCPリセットします。 ECNを交渉TCPホストがECN-セットアップSYNパケットを送信すると、古いTCP実装は予約済みフィールドにそれらのフラグを無視し、それに応答して、プレーンSYN-ACKパケットを送信することが期待されます。しかし、代わりにリセットとECN-セットアップSYNパケットに応答インターネットでいくつかの壊れたファイアウォールやロードバランサがあります。 ECN対応のエンド・ノードの展開に続いて、ECN対応のホストは[Kelson00]ウェブサイトの数にアクセスすることができませんでした広範囲の苦情がありました。これは2002年3月までに、9月から撮影したデータにLinuxコミュニティによると、TBITプロジェクト[TBIT]で2000を検討されており、および[Cou01]今日Enterprise Linuxの中で記事で説明されています。問題のある設備の一部が確認されており、Webページ[修正は非対応製品やベンダーによって投稿修正のリストが含まれています。 ECNが提案標準として承認されました半年後、2002年3月に、ECN-setup SYNパケットをテストした12364のウェブサイトの203からリセットが応答した、とECN-setup SYNパケットは、ウェブサイトの420のために落とされました。ブロックパケットがTCPの予約済みフィールドのフラグを使用していることをソフトウェアをインストールすると、後でそのソフトウェアをアンインストールするよりもかなり簡単です。
A work-around for maintaining connectivity in the face of the broken equipment was described in [Floyd00], and has been specified in RFC 3168 as a procedure that may be included in TCP implementations. We describe this work-around briefly below.
壊れた設備の面で接続性を維持するための回避策は、[Floyd00]で説明し、TCPの実装に含まれていてもよい手順としてRFC 3168に指定されています。当社は、以下に簡単に、この回避策について説明します。
To provide robust connectivity even in the presence of faulty equipment, a TCP host that receives a reset in response to the transmission of an ECN-setup SYN packet may resend the SYN with CWR and ECE cleared. This would result in a TCP connection being established without using ECN. This also has the unfortunate result of the ECN-capable TCP host not responding properly to the first valid reset. If a second reset is sent in response to the second SYN, which had CWR and ECE cleared, then the TCP host should respond properly by aborting the connection.
でも、故障機器の存在下で、強固な接続性を提供するために、ECN-セットアップSYNパケットの送信に応答してリセットを受信TCPホストはクリアCWRとECEでSYNを再送信することができます。これは、ECNを使用せずに確立されたTCP接続につながります。また、これは最初の有効なリセットに適切に応答しないECN対応のTCPホストの不幸な結果を持っています。第2のリセットは、CWRとECEがクリアされていた第二SYN、に応答して送信されている場合、TCPホストは接続を中止することにより、適切に応答する必要があります。
Similarly, a host that receives no reply to an ECN-setup SYN within the normal SYN retransmission timeout interval may resend the SYN and any subsequent SYN retransmissions with CWR and ECE cleared. To overcome normal packet loss that results in the original SYN being lost, the originating host may retransmit one or more ECN-setup SYN packets before giving up and retransmitting the SYN with the CWR and ECE bits cleared.
同様に、通常のSYN再送タイムアウト間隔内ECN-セットアップSYNに応答なしホストはSYNとクリアCWRとECEと後続のSYN再送信を再送信することができます。失われ、元のSYN、その結果、通常のパケットロスを克服するために、元ホストはあきらめとCWRとECEビットをクリアしてSYNを再送する前に、一つ以上のECN-setup SYNパケットを再送信することができます。
Some TCP implementors have so far decided not to deploy these workarounds, for the following reasons:
いくつかのTCP実装者は、これまでに次のような理由から、これらの回避策を展開しないことを決定しました。
* The work-arounds would result in ECN-capable hosts not responding properly to the first valid reset received in response to a SYN packet.
*回避策は、ECN-可能なホストはSYNパケットに応答して受信された最初の有効なリセットに正しく応答しないことになります。
* The work-arounds would limit ECN functionality in environments without broken equipment, by disabling ECN where the first SYN or SYN-ACK packet was dropped in the network.
*回避策は、最初のSYNまたはSYN-ACKパケットがネットワークに滴下しECNを無効にすることによって、破壊装置なしの環境でECN機能を制限します。
* The work-arounds in many cases would involve a delay of six seconds or more before connectivity is established with the remote server, in the case of broken equipment that drops ECN-setup SYN packets. By accommodating this broken equipment, the work-arounds have been judged as implicitly accepting both this delay and the broken equipment that would be causing this delay.
接続がECN-setup SYNパケットをドロップ壊れた機器の場合には、リモートサーバーと確立される前に*多くの場合、回避策は、6秒以上の遅延を伴うだろう。この壊れた機器を収容することにより、回避策は、暗黙的に、この遅延し、この遅延を引き起こすことになる壊れた機器の両方を受け入れるように判定されました。
One possibility would be for such work-arounds to be configurable by the user.
一つの可能性は、ユーザーが設定できるように、このような回避策のためになります。
One unavoidable consequence of the work-around of resending a modified SYN packet in response to a reset is to further erode the semantics of the TCP reset. Thus, when a box sends a reset, the TCP host receiving that reset does not know if the reset was sent simply because of the ECN-related flags in the TCP header, or because of some more fundamental problem. Therefore, the TCP host resends the TCP SYN packet without the ECN-related flags in the TCP header. The ultimate consequence of this absence of clear communications from the middlebox to the end-nodes could be an extended spiral of communications specified for transport protocols, as end nodes attempt to sacrifice as little functionality as possible in the process of determining which packets will and will not be forwarded to the other end. This is discussed in more detail in Section 6.1 below.
リセットに応じて変更されたSYNパケットを再送の回避策の一つ不可避の結果は、さらにTCPリセットの意味を侵食することです。リセットがあるため、TCPヘッダ内のECN関連フラグの、またはので、いくつかのより根本的な問題のため、単純に送信された場合はこのように、ボックスはリセットを送信すると、そのリセットを受信TCPホストは知りません。したがって、TCPホストは、TCPヘッダ内のECN関連フラグ無しTCP SYNパケットを再送します。エンドノードが意志をパケットと意志決定の過程で、可能な限り少ない機能性を犠牲にする試みとして、エンドノードにミドルから明らか通信のこの欠如の最終結果は、トランスポートプロトコルのために指定された通信の拡張螺旋とすることができますもう一方の端に転送されません。これは、以下の6.1節で詳しく説明されています。
4. On Combating Obstacles to the Proper Evolution of the Internet Infrastructure
インターネットインフラの適切な進化への障害と闘う4.
One of the reasons that this issue of inappropriate resets is important (to me) is that it has complicated the deployment of ECN in the Internet (though it has fortunately not blocked the deployment completely). It has also added an unnecessary obstacle to the future effectiveness of ECN.
不適切なリセットのこの問題は（私には）重要である理由の一つは、（それが幸い完全展開をブロックしていないが）、それはインターネットにECNの配備を複雑していることです。また、ECNの将来有効に不必要な障害物を追加しました。
However, a second, more general reason why this issue is important is that the presence of equipment in the Internet that rejects valid TCP packets limits the future evolution of TCP, completely aside from the issue of ECN. That is, the widespread deployment of equipment that rejects TCP packets that use Reserved flags in the TCP header could effectively prevent the deployment of new mechanisms that use any of these Reserved flags. It doesn't matter if these new mechanisms have the protection of Experimental or Proposed Standard status from the IETF, because the broken equipment in the Internet does not stop to look up the current status of the protocols before rejecting the packets. TCP is good, and useful, but it would be a pity for the deployment of broken equipment in the Internet to result in the "freezing" of TCP in its current state, without the ability to use the Reserved flags in the future evolution of TCP.
しかし、この問題は重要である理由秒、より一般的な理由は、有効なTCPパケットを拒否し、インターネットでの機器の存在は完全に脇ECNの問題から、TCPの将来の発展を制限していることです。これは、効果的にこれらの予約済みのフラグのいずれかを使用する新しいメカニズムの展開を防ぐことができるTCPヘッダーに予約済みのフラグを使用するTCPパケットを拒否機器の広範な展開です。インターネットで壊れた機器がパケットを拒否する前に、プロトコルの現在の状態を調べるために停止していないため、これらの新しいメカニズムは、IETFから実験の保護や標準化提案のステータスを持っているかどうかは関係ありません。 TCPは良い、と便利ですが、TCPの将来の発展に予約済みのフラグを使用する機能せず、現在の状態でTCPの「凍結」になるためにインターネットで壊れた機器を展開するための同情だろう。
In the specific case of middleboxes that block TCP SYN packets attempting to negotiate ECN, the work-around described in Section 3.1 is sufficient to ensure that end-nodes could still establish connectivity. However, there are likely to be additional uses of the TCP Reserved Field standardized in the next year or two, and these additional uses might not coexist quite as successfully with middleboxes that send resets. Consider the difficulties that could result if a path changes in the middle of a connection's lifetime, and the middleboxes on the old and new paths have different policies about exactly which flags in the TCP Reserved field they would and would not block.
ECNを交渉しようとしたTCP SYNパケットをブロックする中間ボックスの特定の場合において、ワークアラウンド3.1節に記載されたエンド・ノードが依然として接続を確立することができる保証するのに十分です。しかし、次の1年か2年で標準TCP予約フィールドの追加の用途がありそうであり、これらの追加の用途は、リセットを送信する中間ボックスでそれほど成功し共存しない場合があります。パスは、接続の存続期間の途中で変更し、古いものと新しいパスのミドルボックスが正確にTCP Reservedフィールド中のフラグ、彼らは希望してブロックしないでしょうについて異なるポリシーを持っている場合に生じる可能性の問題を考えてみましょう。
Taking the wider view, the existence of web servers or firewalls that send inappropriate resets is only one example of functionality in the Internet that restricts the future evolution of the Internet. The impact of all of these small restrictions taken together presents a considerable obstacle to the development of the Internet architecture.
広い視野を取ると、不適切なリセットを送信するWebサーバやファイアウォールの存在は、インターネットの将来の発展を制限し、インターネットでの機能のほんの一例です。一緒にこれらの小さな制約の全ての影響は、インターネットアーキテクチャの開発にかなりの障害となっています。
One lesson for designers of transport protocols is that transport protocols will have to protect themselves from the unknown and seemingly arbitrary actions of firewalls, normalizers, and other middleboxes in the network. For the moment, for TCP, this means sending a non-ECN-setup SYN when a reset is received in response to an ECN-setup SYN packet. Defensive actions on the side of transport protocols could include using Reserved flags in the SYN packet before using them in data traffic, to protect against middleboxes that block packets using those flags. It is possible that transport protocols will also have to add additional checks during the course of the connection lifetime to check for interference from middleboxes along the path.
トランスポートプロトコルの設計者のための一つの教訓は、トランスポートプロトコルは、ネットワーク内のファイアウォール、正規化、および他のミドルボックスの不明と一見、任意のアクションから身を守るために持っているということです。現時点では、TCPのために、これはリセットがECN-セットアップSYNパケットに応答して受信されたときに非ECN-セットアップSYNを送ることを意味します。トランスポートプロトコルの側の防御的な行動は、これらのフラグを使用してパケットをブロックする中間から保護するために、データトラフィックでそれらを使用する前に、SYNパケット内のReservedフラグを使用して含めることができます。トランスポートプロトコルはまた、パス上の中間からの干渉をチェックするために、接続の有効期間の途中で追加のチェックを追加する必要があります可能性があります。
The ECN standards document, RFC 3168, contains an extensive discussion in Section 18 on "Possible Changes to the ECN Field in the Network", but includes the following about possible changes to the TCP header:
ECN規格文書は、RFC 3168には、「ネットワークのECNフィールドへの変化の可能性」のセクション18で広範な議論が含まれていますが、TCPヘッダへの変化の可能性について、以下のものが含まれます。
"This document does not consider potential dangers introduced by changes in the transport header within the network. We note that when IPsec is used, the transport header is protected both in tunnel and transport modes [ESP, AH]."
「この文書は、ネットワーク内のトランスポートヘッダ内の変化によって導入潜在的な危険を考慮していない。我々は、[ESP、AH]のIPsecを使用する場合、トランスポート・ヘッダはトンネルおよびトランスポートモードの両方で保護されていることに注意してください。」
With the current modification of transport-level headers in the network by firewalls (as discussed below in Section 6.2), future protocol designers might no longer have the luxury of ignoring the possible impact of changes to the transport header within the network.
（6.2節で後述するように）、ファイアウォールによって、ネットワーク内のトランスポート・レベル・ヘッダーの現在の修正を加えて、将来のプロトコル設計者は、もはやネットワーク内のトランスポート・ヘッダの変更の可能性の影響を無視する贅沢を有していないかもしれません。
Transport protocols will also have to respond in some fashion to an ICMP code of "Communication Administratively Prohibited" if middleboxes start to use this form of the ICMP Destination Unreachable message to indicate that the packet is using functionality not allowed [RFC1812].
トランスポートプロトコルはまた、ミドルボックスは、パケットが[RFC1812]許可されていない機能を使用していることを示すために、ICMP宛先到達不能メッセージのこの形式の使用を開始する場合は、「通信管理上禁止」のICMPコードにいくつかの方法で対応する必要があります。
Given that some middleboxes are going to drop some packets because they use functionality not allowed by the middlebox, the larger issue remains of how middleboxes should communicate the reason for this action to the end-nodes, if at all. One suggestion, for consideration in more depth in a separate document, would be that firewalls send an ICMP Destination Unreachable message with the code "Communication Administratively Prohibited" [B01].
いくつかのミドルボックスは、彼らがミドルで許可されていない機能を使用しているため、いくつかのパケットを廃棄しようとしていることを考えると、大きな問題には全くならばミドルボックスは、エンドノードにこのアクションの理由を伝えるべきかのまま。一つの提案は、別の文書で詳しく検討するために、ファイアウォールが「通信管理上禁止」[B01]のコードでICMP宛先到達不能メッセージを送信することであろう。
We acknowledge that this is not an ideal solution, for several reasons. First, middleboxes along the reverse path might block these ICMP messages. Second, some firewall operators object to explicit communication because it reveals too much information about security policies. And third, the response of transport protocols to such an ICMP message is not yet specified.
これは、いくつかの理由のための理想的な解決策ではないことを認めます。まず、逆の経路上の中間には、これらのICMPメッセージをブロックする可能性があります。それはセキュリティポリシーについてはあまり情報を明らかにしているため第二に、いくつかのファイアウォール事業者は、明示的なコミュニケーションに反対します。そして第三に、このようなICMPメッセージにトランスポートプロトコルの応答がまだ指定されていません。
However, an ICMP "Administratively Prohibited" message could be a reasonable addition, for firewalls willing to use explicit communication. One possibility, again to be explored in a separate document, would be for the ICMP "Administratively Prohibited" message to be modified to convey additional information to the end host.
しかし、ICMP「管理上禁止」のメッセージは、明示的な通信を使用して喜んでファイアウォールのために、合理的な追加である可能性があります。一つの可能性は、再度、別の文書で検討されるように、エンドホストに追加の情報を伝達するように変更されるICMP「管理上禁止」メッセージのためであろう。
We would note that this document does not consider middleboxes that block complete transport protocols. We also note that this document is not addressing firewalls that send resets in response to a TCP SYN packet to a firewalled-off TCP port. Such a use of resets seems consistent with the semantics of TCP reset. This document is only considering the problems caused by middleboxes that block specific packets within a transport protocol when other packets from that transport protocol are forwarded by the middlebox unaltered.
私たちは、この文書は、完全なトランスポートプロトコルをブロックする中間を考慮していないことに注意します。また、この文書はファイアウォールオフTCPポートへのTCP SYNパケットに応答してリセットを送信ファイアウォールに対処されていないことに注意してください。このようなリセットを使用すると、TCPリセットの意味と一致しそうです。この文書は、そのトランスポートプロトコルから他のパケットが変更されていないミドルによって転送されたときに、トランスポートプロトコル内の特定のパケットをブロックする中間ボックスによる問題を検討しています。
One complication is that once a mechanism is installed in a firewall to block a particular functionality, it can take considerable effort for network administrators to "un-install" that block. It has been suggested that tweakable settings on firewalls could make recovery from future incidents less painful all around. Again, because this document does not address more general issues about firewalls, the issue of greater firewall flexibility, and the attendant possible security risks, belongs in a separate document.
1つの複雑機構は、特定の機能をブロックするファイアウォール内に設置されると、それはそのブロックを「アンインストール」するために、ネットワーク管理者のためにかなりの努力を取ることができるということです。ファイアウォールで微調整できる設定はあまり痛みを伴うすべての周り、今後の事故からの回復を作ることができることが示唆されています。この文書は、ファイアウォール、より大きな柔軟性ファイアウォールの問題、および付随する潜在的なセキュリティリスクについて、より一般的な問題に対処していないため、ここでも、別の文書に属します。
Given a firewall that has decided to drop TCP packets that use reserved bits in the TCP header, one question is whether the firewall should also send a Reset, in order to prevent the TCP connection from consuming unnecessary resources at the TCP sender waiting for the retransmit timeout. We would argue that whether or not the firewall feels compelled to drop the TCP packet, it is not appropriate to send a TCP reset. Sending a TCP reset in response to prohibited functionality would continue the current overloading of the semantics of the TCP reset in a way that could be counterproductive all around.
TCPヘッダー内の予約ビットを使用するTCPパケットをドロップすることを決定したファイアウォールを考えると、一つの質問は、ファイアウォールも再送信を待っているTCPの送信者に不必要なリソースを消費するからTCP接続を防ぐために、リセットを送信するかどうかでありますタイムアウト。私たちは、ファイアウォールがTCPパケットをドロップすることを強制感じるかどうか、TCPリセットを送信するために適切ではないと主張するだろう。禁止された機能に応じて、TCPリセットを送信すると、すべての周り逆効果になる可能性の方法でTCPリセットの意味論の現在のオーバーロードを続けるだろう。
As an example, Section 2.3 has already observed that some firewalls send resets in response to TCP SYN packets as a congestion control mechanism. Possibly in response to this (or perhaps in response to something else), some popular TCP implementations immediately resend a SYN packet in response to a reset, up to four times. Other TCP implementations, in conformance to the standards, don't resend SYN packets after receiving a reset. The more aggressive TCP implementations increase congestion for others, but also increase their own chances of eventually getting through. Giving these fluid semantics for the TCP reset, one might expect more TCP implementations to start resending SYN packets in response to a reset, completely apart from any issues having to do with ECN. Obviously, this weakens the effectiveness of the reset when used for its original purpose, of responding to TCP packets that apparently are not intended for the current connection.
一例として、セクション2.3は、既にいくつかのファイアウォールが輻輳制御機構としてのTCP SYNパケットに応答してリセットを送信することを観察しました。おそらくこれに応じて（あるいは何か他に応じて）、いくつかの人気のTCP実装は、すぐに4回まで、リセットに応じて、SYNパケットを再送します。他のTCP実装は、標準に準拠して、リセットを受信した後、SYNパケットを再送しません。より積極的なTCP実装は、他の人のための輻輳を増やすだけでなく、最終的に通り抜けるの自分の可能性を高めます。 TCPリセットのためにこれらの流体のセマンティクスを与え、人はより多くのTCP実装は、ECNに関係することすべての問題から完全に離れて、リセットに応じて、SYNパケットを再送開始するために期待するかもしれません。明らかに、これは明らかに、現在の接続のために意図されていないTCPパケットに応答して、その本来の目的のために使用されるリセットの有効性を、弱めます。
If we add to this mix the use of the TCP reset by firewalls in response to TCP packets using reserved bits in the TCP header, this muddies the waters further. Because TCP resets could be sent due to congestion, or to prohibited functionality, or because a packet was received from a previous TCP connection, TCP implementations (or, more properly, TCP implementors) would now have an incentive to be even more persistent in resending SYN packets in response to TCP resets. In addition to the incentive mentioned above of resending TCP SYN packets to increase one's odds of eventually getting through in a time of congestion, the TCP reset might have been due to prohibited functionality instead of congestion, so the TCP implementation might resend SYN packets in different forms to determine exactly which functionality is being prohibited. Such a continual changing of the semantics of the TCP reset could be expected to lead to a continued escalation of measures and countermeasures between firewalls and end-hosts, with little productive benefit to either side.
我々は、TCPヘッダ内の予約ビットを使用して、TCPパケットに応答して、ファイアウォールによってTCPリセットの使用を混ぜ、これに追加した場合、これはさらに水をmuddies。 TCPリセットパケットは、前のTCPコネクションから受信したので、輻輳に起因する、または禁止された機能に送られ、またはすることができ、TCPの実装（より適切か、TCP実装者は）今再送にも、より持続可能にするインセンティブを持つことになりますのでTCPリセットに応答して、SYNパケット。最終的には混雑時に通り抜けるの1の確率を高めるためにTCP SYNパケットを再送する上記のインセンティブに加えて、TCPリセットではなく、混雑の禁止機能が原因であったかもしれないので、TCPの実装は異なるでSYNパケットを再送するかもしれませんフォームは禁止されている機能を正確に決定します。 TCPリセットの意味論のような連続的な変化は、いずれかの側に少し生産利益と、ファイアウォールとエンドホスト間の測定と対策の継続的なエスカレーションにつながることが期待できます。
It could be argued that *dropping* the TCP SYN packet due to the use of prohibited functionality leads to overloading of the semantics of a packet drop, in the same way that the reset leads to overloading the semantics of a reset. This is true; from the viewpoint of end-system response to messages with overloaded semantics, it would be preferable to have an explicit indication about prohibited functionality (for those firewalls for some reason willing to use explicit indications). But given a firewall's choice between sending a reset or just dropping the packet, we would argue that just dropping the packet does less damage, in terms of giving an incentive to end-hosts to adopt counter-measures. It is true that just dropping the packet, without sending a reset, results in delay for the TCP connection in resending the SYN packet without the prohibited functionality. However, sending a reset has the undesirable longer-term effect of giving an incentive to future TCP implementations to add more baroque combinations of resending SYN packets in response to a reset, because the TCP sender can't tell if the reset is for a standard reason, for congestion, or for the prohibited functionality of option X or reserved bit Y in the TCP header.
*滴下*禁止機能を使用するためのTCP SYNパケットがリセットリセットのセマンティクスを過負荷につながるのと同じように、パケットドロップのセマンティクスの過負荷につながると主張することができます。これは本当です;オーバーロードされたセマンティクスを持つメッセージに対するエンド・システム応答の観点からは、（明示的な表示を使用して喜んで何らかの理由で、これらのファイアウォールのために）禁止機能に関する明確な指示を有することが好ましいであろう。しかし、リセットを送信したり、単にパケットをドロップする間にファイアウォールの選択を考えると、私たちは、パケットをドロップする対策を採用する-ホストを終了するインセンティブを与えるという点で、より少ないダメージを与えることを主張するだろう。ちょうど、禁止機能なしでSYNパケットを再送におけるTCP接続の遅延で結果をリセットを送信せずに、パケットをドロップすることは事実です。リセットは標準のためである場合、TCP送信者が言うことができないのでしかし、リセットを送信することは、リセットに応じて、SYNパケットを再送するより多くのバロック様式の組み合わせを追加するために、将来のTCP実装にインセンティブを与えるのは望ましくない長期的な効果を持っています混雑のために、またはTCPヘッダのオプションXまたは予約ビットYの禁止機能理由、。
In addition to firewalls that send resets in response to ECN-setup SYN packets and firewalls that drop ECN-setup SYN packets, there also exist firewalls that by default zero the flags in the TCP Reserved field, including the two flags used for ECN. We note that in some cases this could have unintended and undesirable consequences.
ECN-セットアップSYNパケットをドロップECN-セットアップSYNパケットをファイアウォールに応答してリセットを送信するファイアウォールに加えて、ECNのために使用される2つのフラグを含むデフォルトでTCP予約フィールドにフラグをゼロファイアウォールは、そこに存在します。私たちは、いくつかのケースで、これは予期しない、望ましくない結果をもたらす可能性があることに注意してください。
If a firewall zeros the ECN-related flags in the TCP header in the initial SYN packet, then the TCP connection will be set up without using ECN, and the ECN-related flags in the TCP header will be sent zeroed-out in all of the subsequent packets in this connection. This will accomplish the firewall's purpose of blocking ECN, while allowing the TCP connection to proceed efficiently and smoothly without using ECN.
最初のSYNパケットにTCPヘッダ内のECN関連フラグは、次にTCP接続がECNを使用せずに設定され、ファイアウォールゼロ、及びTCPヘッダ内のECN関連フラグ場合のすべてにおいてゼロアウト送信されますこれに関連して、後続のパケット。これは、TCP接続がECNを使用せずに、効率的かつ円滑に進行させる一方で、ECNをブロックするファイアウォールの目的を達成します。
If for some reason the ECN-related flags in the TCP header aren't zeroed in the initial SYN packet from host A to host B, but the firewall does zero those flags in the responding SYN/ACK packet from host B to host A, the consequence could be to subvert end-to-end congestion control for this connection. The ECN specifications were not written to ensure robust operation in the presence of the arbitrary zeroing of TCP header fields within the network, because it didn't occur to the authors of the protocol at the time that this was a requirement in protocol design.
何らかの理由でTCPヘッダ内のECN関連フラグがBをホストするホストAからの最初のSYNパケットにゼロにされるのではなく、ファイアウォールがホストするホストBからの応答SYN / ACKパケットにゼロそれらのフラグを行う場合、結果として、この接続のエンドツーエンドの輻輳制御を破壊する可能性があります。 ECNの仕様は、これはプロトコル設計における要件であったことを一度にプロトコルの作者に発生しなかったため、ネットワーク内のTCPヘッダフィールドの任意のゼロ化の存在下で堅牢な動作を保証するために書かれていませんでした。
Similarly, if the ECN-related flags in the TCP header are not zeroed in either the SYN or the SYN/ACK packet, but the firewall does zero these flags in later packets in that TCP connection, this could also have the unintended consequence of subverting end-to-end congestion control for this connection. The details of these possible interactions are not crucial for this document, and are described in the appendix. However, our conclusion, both for the ECN-related flags in the TCP header and for future uses of the four other bits in the TCP Reserved field, would be that if it is required for firewalls to be able to block the use of a new function being added to a protocol, this is best addressed in the initial design phase by joint cooperation between the firewall community and the protocol designers.
TCPヘッダ内のECN関連フラグがSYNまたはSYN / ACKパケットのいずれかにゼロが、ファイアウォールがそのTCP接続の後のパケットにゼロこれらのフラグをしていない場合も同様に、これも破壊するの意図しない結果を有することができますこの接続のエンドツーエンドの輻輳制御。これらの可能な相互作用の詳細は、このドキュメントのために重要ではない、と付録で説明されています。しかし、私たちの結論は、TCPヘッダ内のECN関連フラグのためにとTCPの予約領域における他の4つのビットの将来の使用のために、両方の、ファイアウォールが新しいの使用をブロックできるようにするためにそれが必要な場合ということでしょう関数は、これが最良のファイアウォールのコミュニティとプロトコル設計者間の共同協力により、設計の初期段階で対処され、プロトコルに追加されています。
Our conclusion is that it is not conformant with current standards for a firewall, load-balancer, or web-server to respond with a reset to a TCP SYN packet simply because the packet uses flags in the TCP Reserved field. More specifically, it is not conformant to respond with a reset to a TCP SYN packet simply because the ECE and CWR flags are set in the IP header. We would urge vendors to make available fixes for any nonconformant code, and we could urge ISPs and system administrators to deploy these fixes in their web servers and firewalls.
私たちの結論は、パケットがTCP予約済みフィールドのフラグを使用しているため、単純にTCP SYNパケットにリセットして応答するために、現在のファイアウォールのための規格、ロードバランサ、またはWebサーバーに準拠していないということです。具体的には、ECEとCWRフラグはIPヘッダに設定されているという理由だけで、TCP SYNパケットにリセットして応答するために準拠していません。私たちは、すべての不適合コードのために利用可能な修正を行うためにベンダーを促すだろう、と私たちは、自分のWebサーバやファイアウォールでこれらの修正プログラムを展開するISPやシステム管理者を促すことができます。
We don't claim that it violates any standard for middleboxes to arbitrarily drop packets that use flags in the TCP Reserved field, but we would argue that behavior of this kind, without a clear method for informing the end-nodes of the reasons for these actions, could present a significant obstacle to the development of TCP. More work is clearly needed to reconcile the conflicting interests of providing security while at the same time allowing the careful evolution of Internet protocols.
私たちは、それが任意にTCP予約済みフィールドにフラグを使用するパケットをドロップするミドルボックスのための任意の標準に違反すると主張していないが、我々はこれらの理由のエンドノードに通知するための明確な方法なしに、この種の行動を主張するだろうアクションは、TCPの発展に大きな障害を提示することができます。より多くの作業がはっきりと同時に、インターネット・プロトコルの慎重な進化を可能にしながら、セキュリティを提供するという相反する利害を調整するために必要とされます。
This document results from discussions and activity by many people, so I will refrain from trying to acknowledge all of them here. My specific thanks go to 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, and Dan Wing for feedback on this document, and to the End-to-End Research Group, the IAB, and the IESG for discussion of these issues. I thank Mikael Olsson for numerous rounds of feedback. I also thank the members of the Firewall Wizards mailing list for feedback (generally of disagreement) on an earlier draft of this document.
この文書では、多くの人々によって議論や活動から得られるので、私はここでそれらのすべてを認めるしようとして控えます。私の特定のおかげで蘭にアトキンソン、スティーブBellovin氏、アレックスカンナーラ、デニスファーガソン、ネッドフリード、マーク・ハンドリー、ジョン・クレンシン、アリソンマンキン、Jitendra Padhye、バーン・パクソン、KKラマクリシュナン、ジャマル・ハディサリム、ペッカSavola、アレックス・スノアレン、ダン行きますこれらの問題の議論については、この文書にし、エンドツーエンドの研究グループ、IAB、およびIESGへのフィードバックのためのウィング。私はフィードバックの多数のラウンドのためにミカエル・オルソンに感謝します。また、私はこの文書の以前のドラフトには（一般的に不一致の）フィードバックのためのファイアウォールウィザードメーリングリストのメンバーに感謝します。
Email discussions with a number of people, including Dax Kelson, Alexey Kuznetsov, Kacheong Poon, David Reed, Jamal Hadi-Salim, and Venkat Venkatsubra, have addressed the issues raised by non-conformant equipment in the Internet that does not respond to TCP SYN packets with the ECE and CWR flags set. We thank Mark Handley, Jitentra Padhye, and others for discussions on the TCP initialization procedures.
ダックスKelson、アレクセイ・クズネツォフ、Kacheongプーン、デビッド・リード、ジャマル・ハディ・サリム、およびヴェンカトVenkatsubra含めた人々の数と電子メールの議論は、TCP SYNに応答しないインターネットで非準拠の機器が提起した問題に対処していますECEとCWRフラグがセットされたパケット。我々はマーク・ハンドリー、Jitentra Padhye、およびTCPの初期化手続き上の議論のための他の人に感謝します。
[RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル - DARPAインターネットプログラムプロトコル仕様"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン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, January 1999.
[RFC2481]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP Processing of the IPv4 Precedence Field, RFC 2873, June 2000.
[RFC2873]シャオ、X.、阪南、A.、パクソン、V.、およびE.クラッブ、「IPv4の優先順位フィールドのTCP処理、RFC 2873、2000年6月。
[RFC2979] Freed, N., " Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]フリード、N.、 "の行動とインターネットファイアウォールの要件"、RFC 2979、2000年10月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K.、フロイド、S.及びD.ブラック、 "IPに明示的輻輳通知（ECN）の追加"、RFC 3168、2001年9月。
[B01] Bellovin, S., "A "Reason" Field for ICMP "Administratively Prohibited" Messages", Work in Progress.
[B01] Bellovin氏、S.、 "A "理由" ICMPのフィールド "管理上禁止" メッセージ"、ProgressのWork。
[Cou01] Scott Courtney, Why Can't My 2.4 Kernel See Some Web Sites?, Enterprise Linux Today, Apr 17, 2001. URL "http://eltoday.com/article.php3?ltsn=2001-04-17-001-14- PS".
[Cou01]私の2.4カーネルは、一部のWebサイトを参照してくださいすることはできませんなぜスコット・コートニー、？、エンタープライズLinuxの今日、4月17日、2001年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".
[ECN] "ECNのWebページ" URL "http://www.icir.org/floyd/ecn.html"。
[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL "http://gtf.org/garzik/ecn/".
[解決] ECN-アンダーLinuxの非公式のベンダーサポートページ、URL "http://gtf.org/garzik/ecn/"。
[Floyd00] Sally Floyd, Negotiating ECN-Capability in a TCP connection, October 2, 2000, email to the end2end-interest mailing list. URL "http://www.icir.org/floyd/papers/ECN.Oct2000.txt".
TCP接続、2000年10月2日、end2end金利メーリングリストへの電子メールでECN-能力を交渉[Floyd00]サリーフロイド、。 URL "http://www.icir.org/floyd/papers/ECN.Oct2000.txt"。
[Kelson00] Dax Kelson, note sent to the Linux kernel mailing list, September 10, 2000.
[Kelson00]ダックスKelson、ノートは2000年9月10日、Linuxカーネルのメーリングリストに送られました。
[QUESO] Toby Miller, Intrusion Detection Level Analysis of Nmap and Queso, August 30, 2000. URL "http://www.securityfocus.com/infocus/1225".
[ケソ]トビー・ミラー、Nmapのとケソの侵入検知レベルの分析、8月30日、2000年URL「http://www.securityfocus.com/infocus/1225」。
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94]スティーブンス、W.、 "TCP / IPイラスト、第1巻：プロトコル"、アディソン・ウェズリー、1994。
[SFO01] FreeBSD ipfw Filtering Evasion Vulnerability, Security Focus Online, January 23, 2001. URL "http://www.securityfocus.com/bid/2293".
[SFO01] FreeBSDのipfwのフィルタリング回避の脆弱性、セキュリティフォーカスオンライン、1月23日、2001年URL "http://www.securityfocus.com/bid/2293"。
[TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP Behavior of Web Servers, SIGCOMM, August 2001. URL "http://www.icir.org/tbit/".
[TBIT] Jitendra Padhyeとサリーフロイド、WebサーバのTCPの挙動を識別、SIGCOMM、2001年8月URL "http://www.icir.org/tbit/"。
One general risk of using Reserved flags in TCP is the risk of providing additional information about the configuration of the host in question. However, TCP is sufficiently loosely specified as it is, with sufficiently many variants and options, that port-scanning tools such as Nmap and Queso do rather well in identifying the configuration of hosts even without the use of Reserved flags.
TCPで予約済みのフラグを使用する1つの一般的なリスクは、問題のホストの構成に関する追加情報を提供するリスクです。しかし、そのままではTCPが十分に緩く十分に多くの変形およびオプションで、指定されている、などのNmapやケソとしてそのポートスキャンツールでも予約済みのフラグを使用せずに、ホストの構成を特定するにはかなりうまくやって。
The security considerations and all other considerations of a possible ICMP Destination Unreachable message with the code "Communication Administratively Prohibited" will be discussed in a separate document.
セキュリティ上の考慮事項とコード「通信管理上禁止」で可能なICMP宛先到達不能メッセージの他のすべての考慮事項は、別の文書で説明します。
The traditional concern of firewalls is to prevent unauthorized access to systems, to prevent DoS attacks and other attacks from subverting the end-user terminal, and to protect end systems from buggy code. We are aware of one security vulnerability reported from the use of the Reserved flags in the TCP header [SFO01]. A packet filter intended only to let through packets in established connections can let pass a packet not in an established connection if the packet has the ECE flag set in the reserved field. "Exploitation of this vulnerability may allow for unauthorized remote access to otherwise protected services." It is also possible that an implementation of TCP could appear that has buggy code associated with the use of Reserved flags in the TCP header, but we are not aware of any such implementation at the moment.
ファイアウォールの伝統的な懸念は、システムへの不正アクセスを防止するために、エンドユーザ端末を破壊するからDoS攻撃やその他の攻撃を防ぐために、およびバグのあるコードからエンドシステムを保護することです。私たちは、TCPヘッダ[SFO01]で予約フラグの使用から報告された1件のセキュリティ上の脆弱性を認識しています。唯一の確立された接続内のパケットを通過させることを意図し、パケットフィルタは、パケットが予約フィールドに設定されたECEフラグを持っている場合ではない確立された接続パケットを通過させることができます。 「この脆弱性の悪用は、それ以外の場合は保護されたサービスへの不正なリモートアクセスを可能にすることができます。」 TCPの実装では、それはTCPヘッダー内の予約フラグの使用に関連したバグのあるコードを持って現れる可能性もあるが、私たちは、現時点ではどのような実装を認識していません。
Unfortunately, misconceived security concerns are one of the reasons for the problems described in this document in the first place. An August, 2000, article on "Intrusion Detection Level Analysis of Nmap and Queso" described the port-scanning tool Queso as sending SYN packets with the last two Reserved bits in the TCP header set, and said the following: "[QUESO] is easy to identify, if you see [these two Reserved bits and the SYN bit] set in the 13th byte of the TCP header, you know that someone has malicious intentions for your network." As is documented on the TBIT Web Page, the middleboxes that block SYNs using the two ECN-related Reserved flags in the TCP header do not block SYNs using other Reserved flags in the TCP header.
残念ながら、誤認セキュリティ上の懸念は、最初の場所で、この文書で説明する問題の原因の一つです。 2000年8月、「Nmapのとケソの侵入検知レベル分析」の記事は、TCPヘッダセット内の最後の2つの予約ビットでSYNパケットを送信するようにポートスキャンツールケソを説明し、かつ以下の言った：「[ケソ]はあなたはTCPヘッダの13バイトに設定し、[これらの2つの予約ビットとSYNビット]を参照してください場合は、特定しやすいが、誰かがあなたのネットワークのための悪質な意図を持っていることを知っています。」 TBITのWebページに記述されたように、TCPヘッダ二つECN関連予約フラグを使用してのSYNをブロックする中間ボックスは、TCPヘッダ内の他の予約フラグを使用してのSYNをブロックしません。
One lesson appears to be that anyone can effectively "attack" a new TCP function simply by using that function in their publicly-available port-scanning tool, thus causing middleboxes of all kinds to block the use of that function.
1回のレッスンは、誰もが効果的にできることのように見える「攻撃」は、単にその機能の使用をブロックするために、あらゆる種類のミドルボックスを引き起こしので、彼らの公的に利用可能なポートスキャンツールでその機能を使用して新しいTCP機能。
In this section we first show that if the ECN-related flags in the TCP header aren't zeroed in the initial SYN packet from Host A to Host B, but are zeroed in the responding SYN/ACK packet from Host B to Host A, the consequence could be to subvert end-to-end congestion control for this connection.
このセクションでは、我々は最初のTCPヘッダ内のECN関連フラグがホストBにホストAからの最初のSYNパケットにゼロにされていない場合ことを示しているが、ホストするホストBからの応答SYN / ACKパケットにゼロにされ、結果として、この接続のエンドツーエンドの輻輳制御を破壊する可能性があります。
Assume that the ECN-setup SYN packet from Host A is received by Host B, but the ECN-setup SYN/ACK from Host B is modified by a firewall in the network to a non-ECN-setup SYN/ACK, as in Figure 3 below. RFC 3168 does not specify that the ACK packet in any way should echo the TCP flags received in the SYN/ACK packet, because it had not occurred to the designers that these flags would be modified within the network.
ホストAからECN-セットアップSYNパケットがホストBによって受信されるが、ホストBからECN-セットアップSYN / ACKは、図のように、非ECN-セットアップSYN / ACKをネットワークにファイアウォールによって修飾されていると仮定下記3。 RFC 3168は、これらのフラグは、ネットワーク内で変更されることをデザイナーに起こっていなかったので、どのような方法でのACKパケットは、SYN / ACKパケットで受信したTCPフラグをエコーするように指定しません。
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
Figure 3: ECN-related flags in SYN/ACK packet cleared in network.
図3：ネットワークでクリアSYN / ACKパケット中のECN関連フラグ。
Following RFC 3168, Host A has received a non-ECN-setup SYN/ACK packet, and must not set ECT on data packets. Host B, however, does not know that Host A has received a non-ECN-setup SYN/ACK packet, and Host B may set ECT on data packets. RFC 3168 does not require Host A to respond properly to data packets received from Host B with the ECT and CE codepoints set in the IP header. Thus, the data sender, Host B, might never be informed about the congestion encountered in the network, thus violating end-to-end congestion control.
RFC 3168に続いて、ホストAは、非ECN-セットアップSYN / ACKパケットを受信した、データパケットにECTを設定してはいけません。ホストB、ただし、Aは、非ECN-セットアップSYN / ACKパケットを受信した、とホストBは、データパケットにECTを設定してそのホストを知りません。 RFC 3168は、IPヘッダに設定されたパケットはECTとホストBから受信したデータとCEコードポイントに適切に応答するためにホストAを必要としません。このように、データ送信側、ホストBは、このようにエンドツーエンドの輻輳制御に違反し、ネットワークで発生した輻輳について通知されない可能性があります。
Next we show that if the ECN-related flags in the TCP header are not zeroed in either the SYN or the SYN/ACK packet, but the firewall does zero these flags in later packets in that TCP connection, this could also have the unintended consequence of subverting end-to-end congestion control for this connection. Figure 4 shows this scenario.
次はTCPヘッダ内のECN関連フラグがSYNまたはSYN / ACKパケットのいずれかにゼロにされていませんが、ファイアウォールがそのTCPコネクションの後半パケットでゼロこれらのフラグをした場合、これはまた、意図せぬ結果を持っている可能性があることを示しますこの接続のエンドツーエンドの輻輳制御を破壊するの。図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
Figure 4: ECN-related flags in ACK packet cleared in network.
図4：ネットワークでクリアACKパケット中のECN関連フラグ。
The ECN-related flags are not changed by the network in the ECN-setup SYN and SYN/ACK packets for the scenario in Figure 4, and both end nodes are free to use ECN, and to set the ECT flag in the ECN field in the IP header. However, if the firewall clears the ECE flag in the TCP header in ACK packets from Node A to Node B, then Node B will never hear about the congestion that its earlier data packets encountered in the network, thus subverting end-to-end congestion control for this connection.
ECN関連フラグは、図4のシナリオにおいて、ECN-セットアップSYNおよびSYN / ACKパケットにネットワークによって変更され、両端のノードがECNを使用して自由であり、でECNフィールドにECTフラグを設定しないようにされていますIPヘッダー。ファイアウォールは、ノードAからノードBへACKパケットにおけるTCPヘッダ中のECEフラグをクリアした場合しかし、その後、ノードBは、このように、エンドツーエンドの輻輳を覆す、その以前のデータパケットがネットワークに遭遇したことの混雑について聞くことはありませんこの接続のための制御。
Additional complications will arise when/if the use of the ECN nonce in TCP becomes standardized in the IETF [RFC3168], as this could involve the specification of an additional flag from the TCP Reserved field for feedback from the TCP data receiver to the TCP data sender. The primary motivation for the ECN nonce is to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set.
追加の合併症が生じることになる場合/これはTCPデータに対してTCPデータ受信装置からのフィードバックのためにTCP予約フィールドからの追加フラグの指定を伴う可能性としてTCPにおけるECN時nonceを使用することは、IETF [RFC3168]で標準になった場合送信者。 ECNナンスのための主要な動機は、データ送信側のためのメカニズムは、そのネットワーク要素がCEコードポイントを消去されず、そのデータ受信器が適切にCEコードポイントセットで送信側にパケットの受信を報告されていることを確認できるようにすることです。
There are no IANA considerations in this document.
この文書にはIANAの考慮事項はありません。
Sally Floyd ICIR (ICSI Center for Internet Research)
サリーフロイドICIR（インターネットリサーチのためのICSIセンター）
Phone: +1 (510) 666-2989 EMail: floyd@icir.org URL: http://www.icir.org/floyd/
電話：+1（510）666-2989 Eメール：floyd@icir.org URL：http://www.icir.org/floyd/
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。