[要約] 要約：RFC 3360は、不適切なTCPリセットの使用がネットワークに悪影響を与える可能性があることを指摘している。 目的：このRFCの目的は、ネットワークの安定性と信頼性を向上させるために、不適切なTCPリセットの使用を減らすことを促すことです。
Network Working Group S. Floyd
Request for Comments: 3360 ICIR
BCP: 60 August 2002
Category: Best Current Practice
Inappropriate TCP Resets Considered Harmful
不適切なTCPリセットは有害であると考えられています
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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ヘッダーでRST（リセット）ビットを使用して、TCP接続をリセットします。リセットは、たとえば、存在しない接続への接続要求に応じて適切に送信されます。リセットの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サーバーとファイアウォールを管理者に通知するために書かれています[修正]。このドキュメントの2番目の目的は、インターネット内のプロトコルのより一般的な進化に対するこのようなミドルボックスの動作の長期的な結果を考慮することです。
2. The history of TCP resets.
2. TCPリセットの履歴。
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には、1981年9月にTCPの元の仕様が含まれていました[RFC793]。このドキュメントでは、TCPヘッダーの最初のビットを定義し、古い重複接続の開始が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.
したがって、RFC 793またはRFC 1122には、SynパケットがTCPヘッダーで予約されたフラグを使用し、RFC 793がこの理由でリセットを送信することを明示的に禁止するという理由だけで、リセットを送信することが許容できることを示唆するものは何もありません。
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のJon Postelの有名な堅牢性の原則が含まれています。RFC 1122は、この堅牢性の原則は「インターネットレイヤーで特に重要であることが特に重要であり、1人の不正なホストが他の多くのホストに対するインターネットサービスを拒否できる」と繰り返します。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でのフレーズは、上記のセクションで説明するように、ゼロでないフィールドを持つTCPパケットに応答してリセットを送信することはできません。
RFC 2979 on the Behavior of and Requirements for Internet Firewalls [RFC2979], an Informational RFC, contains the following:
情報RFCであるインターネットファイアウォールの動作と要件に関するRFC 2979 [RFC2979]には、以下が含まれています。
"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."
「この要件に必要な結果は、そのような障害が発生した場合、ファイアウォールと関連するソフトウェアが問題に対処するために義務付けられていることです。既存の標準プロトコルまたはプロトコル自体の実装の変更を必要としないでください。」
"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パケットに応答してリセットを渋滞制御メカニズムとして送信します。たとえば、リッスンキューがいっぱいです。これらのリセットは、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フィールドの（古い）優先順位フィールドを指します。「セキュリティ」と「コンパートメント」とは、時代遅れのIPセキュリティオプションを指します。書かれたとき、これは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が受信したすべてのセグメントの優先順位を無視する必要があり、優先順位フィールドの変更に応じてリセットを送信してはならないことを指定しています。これについては、この問題が非ゼロTCP予約フィールドを持つセグメントに応答してリセットを送信することを許可されなかったことを明確にするために説明します。
RFC 1122 says the following in Section 4.2.2.5 about TCP options [RFC1122]:
RFC 1122は、TCPオプションに関するセクション4.2.2.5で以下を述べています[RFC1122]：
"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."
「TCPは任意のセグメントでTCPオプションを受信できる必要があります。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月から2001年6月まで、改訂された文書[RFC3168]が提案された標準として承認された実験的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]の予約フィールドから割り当てられた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：TCPヘッダーのバイト13および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：RFC 3168からのTCPヘッダーのバイト13および14の現在の定義。
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ヘッダーの予約フィールドの最後の2つのビットから定義されています。TCPヘッダーの予約フィールドのビット9は、ECNエコーフラグ（ECE）として指定され、ビット8はうっ血ウィンドウが減少した（CWR）フラグとして指定されます。ECNの使用を交渉するために、TCP送信者は、ECEおよびCWRフラグセットを使用したTCP Synパケットである「ECN-Setup Synパケット」を送信します。反対側のTCPホストがこの接続にECNを使用することを希望する場合、ECEフラグセットを備えたTCP synパケットである「ECN-Setup syn-ackパケット」を送信し、CWRフラグは設定されていません。それ以外の場合、反対側の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リセットに戻ります。TCPホストの交渉ECNがECNセットアップSynパケットを送信すると、古いTCP実装は、予約済みのフィールドのフラグを無視し、それに応じてプレーンSyn-ackパケットを送信することが期待されます。ただし、インターネットには、リセットを備えたECNセットアップSynパケットに対応する代わりに、いくつかの壊れたファイアウォールとロードバランサーがあります。ECN対応のENDノードの展開に続いて、ECN対応ホストが多くのWebサイトにアクセスできないという広範な苦情がありました[Kelson00]。これは、Linuxコミュニティ、および2000年9月から2002年3月までに撮影されたデータのTBITプロジェクト[TBIT]によって調査されており、今日のEnterprise Linuxの記事[COU01]で議論されています。問題のある機器の一部が特定されており、Webページ[修正]には、非準拠製品とベンダーが投稿した修正のリストが含まれています。2002年3月、ECNが提案された標準として承認されてから6か月後、ECNセットアップSynパケットは、テストされた12,364のWebサイトのうち203からリセットされ、420のWebサイトでECNセットアップSynパケットがドロップされました。TCPの予約済みフィールドのフラグを使用してパケットをブロックするソフトウェアをインストールすることは、後でそのソフトウェアをアンインストールするよりもかなり簡単です。
3.1. ECN: The Work-Around.
3.1. ECN：ワークアラウンド。
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ホストが最初の有効なリセットに適切に応答しないという不幸な結果もあります。CWRとECEがクリアされた2番目のSynに応じて2番目のリセットが送信される場合、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およびその後のSynの再送信をCWRとECEがクリアします。元のSynが失われる通常のパケット損失を克服するために、発信元のホストは、CWRおよびECEビットをgivingめて再送信する前に、1つまたは複数のECNセットアップ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.
* 作業アラウンドは、synパケットに応じて受信した最初の有効なリセットに適切に応答しないECN対応ホストになります。
* 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セットアップSynパケットをドロップする壊れた機器の場合、リモートサーバーで接続が確立されるまでに6秒以上の遅延が含まれます。この壊れた機器に対応することにより、作業アラウンドは、この遅延とこの遅延を引き起こす壊れた機器の両方を暗黙的に受け入れると判断されました。
One possibility would be for such work-arounds to be configurable by the user.
1つの可能性は、そのような作業アラウンドがユーザーが構成可能にすることです。
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パケットを控えるという作業アラウンドの避けられない結果の1つは、TCPリセットのセマンティクスをさらに侵食することです。したがって、ボックスがリセットを送信すると、そのリセットを受信するTCPホストは、TCPヘッダーのECN関連フラグのために、またはより基本的な問題のために、リセットが送信されたかどうかを知りません。したがって、TCPホストは、TCPヘッダーにECN関連フラグがないTCP Synパケットを再送信します。ミドルボックスからエンドノードへの明確な通信がこの存在しないことの究極の結果は、エンドノードがどのパケットがどのパケットと意志を決定するかを決定するプロセスで可能な限り機能性を犠牲にしようとするため、輸送プロトコルに指定された通信の拡張スパイラルである可能性があります。もう一方の端に転送されないでください。これについては、以下のセクション6.1で詳しく説明します。
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.
この不適切なリセットの問題が重要である理由の1つは（私にとって）重要であることです。インターネットでの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.
ただし、この問題が重要である2番目のより一般的な理由は、有効な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で説明されている作業は、エンドノードがまだ接続性を確立できるようにするのに十分です。ただし、来年または2年に標準化されたTCP予約フィールドの追加の使用がある可能性が高く、これらの追加の使用は、リセットを送信するミドルボックスとはまったくうまく共存しない可能性があります。接続の寿命の途中でパスが変化し、古いパスと新しいパスのミドルボックスには、TCP予約フィールドのどのフラグがブロックしないかについて正確に異なるポリシーがある場合に生じる可能性のある困難を考慮してください。
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.
輸送プロトコルのデザイナーの1つの教訓は、輸送プロトコルがネットワーク内のファイアウォール、ノーマライザー、およびその他のミドルボックスの未知で一見arbitrary意的なアクションから身を守らなければならないことです。現時点では、TCPの場合、これは、ECNセットアップSynパケットに応じてリセットを受信したときにECNセットアップ以外のSynを送信することを意味します。輸送プロトコルの側面における防御アクションには、データトラフィックで使用する前にSynパケットで予約済みフラグを使用して、それらのフラグを使用してパケットをブロックするミドルボックスから保護することが含まれます。また、パスに沿ったミドルボックスからの干渉をチェックするために、接続寿命の過程で輸送プロトコルを追加する必要がある可能性があります。
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には、セクション18で「ネットワーク内のECNフィールドの可能性のある変更」に関する広範な議論が含まれていますが、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]."
「このドキュメントでは、ネットワーク内のトランスポートヘッダーの変更によって導入される潜在的な危険を考慮していません。IPSECを使用すると、トンネルモードと輸送モードの両方で輸送ヘッダーが保護されていることに注意してください[ESP、AH]。」
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].
輸送プロトコルは、この形式のICMP宛先の到達不可能なメッセージを使用して、パケットが機能性を使用していないことを示す[RFC1812]を示している場合、輸送プロトコルは「管理上禁止」の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].
一部のミドルボックスは、ミドルボックスで許可されていない機能を使用しているため、一部のパケットをドロップすることを考えると、ミドルボックスがこのアクションの理由をエンドノードに伝える方法のより大きな問題は、あったとしても、より大きな問題の残りです。別のドキュメントでより深く考慮するために、1つの提案は、ファイアウォールが「管理的に禁止されている」コードを使用してICMP宛先の到達不可能なメッセージを送信することです[B01]。
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の「管理上禁止」メッセージは合理的な追加になる可能性があります。再び別のドキュメントで調査される可能性の1つは、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リセットのセマンティクスと一致しているようです。このドキュメントは、その輸送プロトコルの他のパケットがMiddleboxによって転送されていない場合に、トランスポートプロトコル内の特定のパケットをブロックするミドルボックスによって引き起こされる問題を考慮しています。
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リセットを送信すると、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リセットにこれらの流体セマンティクスを提供すると、ECNに必要な問題とは別に、リセットに応じてSynパケットを控えることがさらに多くのTCP実装が開始することを期待するかもしれません。明らかに、これは元の目的に使用される場合、現在の接続を意図していない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リセットの使用を使用すると、これはさらに水を泥だらけにします。TCPリセットは、混雑または禁止機能のために送信される可能性があるため、または以前のTCP接続からパケットが受信されたため、TCP実装（またはより適切に、TCP実装者）には、復活がさらに持続するインセンティブがあります。TCPリセットに応答したSynパケット。TCP synパケットを控えることの上記のインセンティブに加えて、うっ血の時に最終的に通過する可能性を高めるために、TCPリセットは輻輳の代わりに機能性が禁止されているためである可能性があるため、TCP実装は異なるもののシンパケットを再送信する可能性があります。どの機能が禁止されているかを正確に決定するフォーム。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実装にインセンティブを与えるという望ましくない長期的な効果があります。リセットに応じてリセットに応じてリセットのバロック様式の組み合わせを追加します。これは、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関連フラグはすべてのゼロで送信されます。これに関連する後続のパケット。これにより、ECNをブロックするというファイアウォールの目的が達成され、ECNを使用せずにTCP接続を効率的かつスムーズに進めることができます。
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関連フラグがホストAからホストBまでの初期synパケットでゼロになっていないが、ファイアウォールは、ホストBからホストAに応答する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.
私たちの結論は、ファイアウォール、ロードバランサー、またはWebサーバーの現在の標準に準拠していないということです。TCPSynパケットにリセットされたPacketがTCP予約フィールドのフラグを使用するという理由だけで応答します。より具体的には、ECEとCWRフラグがIPヘッダーに設定されているという理由だけで、TCP Synパケットにリセットされて応答することは適切ではありません。ベンダーに、不適合コードの修正を利用できるように促し、ISPとシステム管理者にこれらの修正をWebサーバーとファイアウォールに展開するよう促すことができます。
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.
このドキュメントは、多くの人々による議論と活動から生じるので、私はここでそれらすべてを認めようとすることを控えます。ラン・アトキンソン、スティーブ・ベロヴィン、アレックス・カンナラ、デニス・ファーガソン、ネッド・フリード、マーク・ハンドリー、ジョン・クレンシン、アリソン・マンキン、ジテンドラ・パディー、ヴァーン・パクソン、K・K・ラマクリシュナン、ジャマル・ハディ・サリム、ペッカ・サヴォラ、アレックス・スノーレン、ダンこのドキュメントに関するフィードバック、およびこれらの問題について議論するためのエンドツーエンドの研究グループ、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.
Dax Kelson、Alexey Kuznetsov、Kacheong Poon、David Reed、Jamal Hadi-Salim、およびVenkat Venkatsubraなど、多くの人々とのメールディスカッションは、TCP Synに応答しないインターネットの不適合機器によって提起された問題に対処しています。ECEおよびCWRフラグセットを備えたパケット。Mark Handley、Jitentra Padhyeなど、TCP初期化手順に関する議論について感謝します。
[RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル-DARPAインターネットプログラムプロトコル仕様」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Ramakrishnan、K。およびS. Floyd、「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] Xiao、X.、Hannan、A.、Paxson、V。、およびE. Crabbe、「TCP処理IPv4 Precentenceフィールド、RFC 2873、2000年6月。
[RFC2979] Freed, N., " Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979] Freed、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] Ramakrishnan、K.、Floyd、S。およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[B01] Bellovin, S., "A "Reason" Field for ICMP "Administratively Prohibited" Messages", Work in Progress.
[B01] Bellovin、S。、「ICMP」の「A Teason」フィールド「Aが禁止されている「メッセージ」」、進行中の作業。
[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] Scott Courtney、なぜ私の2.4カーネルがいくつかのWebサイトを見ることができないのですか？、Enterprise Linux Today、2001年4月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-under-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".
[Floyd00] Sally Floyd、2000年10月2日、TCP接続でのECNキャピールの交渉、End2end-Interestメーリングリストにメール。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] Dax 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".
[Queso] Toby Miller、NMAPおよびQuesoの侵入検知レベル分析、2000年8月30日。URL「http://www.securityfocus.com/infocus/1225」。
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94] Stevens、W。、「TCP/IP Illustrated、Volume 1：The Protocols」、Addison-Wesley、1994。
[SFO01] FreeBSD ipfw Filtering Evasion Vulnerability, Security Focus Online, January 23, 2001. URL "http://www.securityfocus.com/bid/2293".
[SFO01] FreeBSD IPFWフィルタリング回避脆弱性、セキュリティフォーカスオンライン、2001年1月23日。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とSally Floyd、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やQuesoなどのポートスキャンツールは、予約されたフラグを使用しなくてもホストの構成を識別するのにかなりうまく機能します。
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宛先の到達不可能なメッセージの可能性のあるすべての考慮事項「Communication Admentially禁止」については、別のドキュメントで説明されます。
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.
残念ながら、セキュリティ上の懸念の誤った懸念は、そもそもこの文書で説明されている問題の理由の1つです。2000年8月、「NMAPとQuesoの侵入検知レベル分析」に関する記事は、ポートスキャンツールのQuesoがTCPヘッダーセットの最後の2つの予約ビットのSynパケットを送信し、次のように述べています。識別が簡単です。[これら2つの予約済みビットとsynビット]がTCPヘッダーの13バイトに設定されている場合、誰かがネットワークに悪意のある意図を持っていることがわかります。」TBIT Webページに記載されているように、TCPヘッダーの2つの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関連フラグがホストAからホストBまでの最初のSynパケットでゼロになっていないが、ホストBからホストAに応答する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は、図のようにネットワーク内のファイアウォールによって変更されていない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およびCEコードポイントを使用して、ホストBから受信したデータパケットに適切に応答するようにホスト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でのECN NonCEの使用がIETF [RFC3168]で標準化されると//TCPデータレシーバーからTCPデータレシーバーへのフィードバックのためにTCP予約フィールドからの追加フラグの仕様が含まれる可能性があるため、追加の合併症が発生します。送信者。ECN NonCeの主な動機は、データ送信者がネットワーク要素がCEコードポイントを消去しておらず、データ受信機がCE CodePointセットを使用してパケットの受信を送信者に適切に報告していることを確認するためのメカニズムを許可することです。
There are no IANA considerations in this document.
このドキュメントにはIANAの考慮事項はありません。
Sally Floyd ICIR (ICSI Center for Internet Research)
Sally Floyd ICIR（ICSIセンターのインターネット研究）
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。