Internet Engineering Task Force (IETF) M. Bashyam
Request for Comments: 6429 Ocarina Networks, Inc.
Category: Informational M. Jethanandani
ISSN: 2070-1721 A. Ramaiah
Cisco
December 2011
TCP Sender Clarification for Persist Condition
Abstract
抽象
This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122.
この文書は、RFC 1122（「 - 通信層インターネットホストの要件」）で説明したゼロウィンドウプローブ（ZWPs）を明確にしています。特に、ZWP条件を経験している接続上で実行できるアクションを明確にしています。むしろ標準への変更を行うよりも、この文書はRFC 1122で指定されている、今までの標準の誤解されているものを明確にしています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6429.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6429で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Discussion of RFC 1122 Requirement ..............................3
3. Description of One Simple Attack ................................4
4. Clarification Regarding RFC 1122 Requirements ...................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................5
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
Section 4.2.2.17 of "Requirements for Internet Hosts -- Communication Layers" [RFC1122] says:
「インターネットホストのための要件 - 通信層」のセクション4.2.2.17 [RFC1122]は言います：
"A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open.
「TCPはキープMAYその受信提供ウィンドウが無限に閉じました。限り受信側TCPが、プローブセグメントに応じて、確認応答を送信し続けると、送信TCP接続が開いたままに許容しなければなりません。
DISCUSSION:
討論：
It is extremely important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP".
データを含まないACK（確認応答）セグメントが確実に「TCPによって送信されていないことを覚えておくことが非常に重要です。
Therefore, zero window probing needs to be supported to prevent a connection from hanging forever if ACK segments that re-open the window are lost. The condition where the sender goes into the Zero Window Probe (ZWP) mode is typically known as the 'persist condition'.
したがって、ゼロウィンドウは、ウィンドウを再度開くACKセグメントが失われた場合、永遠にハングからの接続を防ぐためにサポートする必要性をプロービングします。送信者がゼロウィンドウプローブ（ZWP）モードに入る条件は、典型的には、「条件を永続」として知られています。
This guidance is not intended to preclude resource management by the operating system or application, which may request that connections be aborted regardless of whether or not they are in the persist condition. The TCP implementation needs to, of course, comply by aborting such connections. If such resource management is not performed external to the protocol implementation, TCP implementations that misinterpret Section 4.2.2.17 of [RFC1122] have the potential to make systems vulnerable to denial-of-service (DoS) [RFC4732] scenarios where attackers tie up resources by keeping connections in the persist condition.
このガイダンスは、接続に関係なく、それらが持続状態にあるか否かを中止することを要求することができるオペレーティングシステムまたはアプリケーションによるリソース管理を排除するものではありません。 TCPの実装は、当然のことながら、このような接続を中断することにより、遵守する必要があります。このようなリソース管理がプロトコル実装の外部行われていない場合は、[RFC1122]のセクション4.2.2.17を誤解TCP実装は、攻撃者がリソースを拘束サービス拒否（DoS）[RFC4732]シナリオにシステムが脆弱にする可能性を有します存続の条件で接続を維持することもできます。
Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122 [RFC1122].
むしろ標準への変更を行うよりも、この文書はRFC 1122 [RFC1122]で指定されている、今までの標準の誤解されているものを明確にしています。
Section 2 of this document describes why implementations might not close connections merely because they are in the persist condition, yet need to still allow such connections to be closed on command. Section 3 outlines a simple attack on systems that do not sufficiently manage connections in this state. Section 4 concludes with a requirements-language clarification to the RFC 1122 requirement.
実装は接続に近い単に彼らが持続状態にあるが、それでもこのような接続は、コマンドで閉じることができるようにする必要はないかもしれませんので、なぜこのドキュメントのセクション2は説明しています。第3節では、十分にこの状態の接続を管理していないシステム上の単純な攻撃の概要を説明します。第4節では、RFC 1122の要件に要件言語明確で終了します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書では[RFC2119]で説明されるように解釈されるべきです。
Per [RFC1122], as long as the ACKs are being received for window probes, a connection can continue to stay in the persist condition. This is an important feature, because applications typically would want the TCP connection to stay open unless an application explicitly closes the connection.
[RFC1122]あたり、限りACKがウィンドウプローブのために受信されているように、接続が永続状態に滞在し続けることができます。アプリケーションは通常、アプリケーションが明示的に接続を閉じない限り、TCP接続が開いたままにしたいと思うので、これは、重要な機能です。
For example, take the case of a user running a network print job during which the printer runs out of paper and is waiting for the user to reload the paper tray (user intervention). The printer may not be reading data from the printing application during this time.
例えば、プリンタが用紙を使い果たし、ユーザが用紙トレイ（ユーザの介入）を再ロードするのを待っている間にネットワーク印刷ジョブを実行しているユーザーの場合を取ります。プリンタは、この期間中に印刷アプリケーションからデータを読み込むことはできません。
Although this may result in a prolonged ZWP state, it would be premature for TCP to take action on its own and close the printer connection merely due to its lack of progress. Once the printer's paper tray is reloaded (which may be minutes, hours, or days later), the print job needs to be able to continue uninterrupted over the same TCP connection.
これは長期のZWP状態をもたらすことができるが、TCPは独自に行動を取るとによる進展の欠如に単にプリンタ接続をクローズすることは時期尚早だろう。プリンタの用紙トレイが（分、時間、または日後でもよい）にリロードされると、印刷ジョブは同じTCP接続を介して中断せず継続できるようにする必要があります。
However, systems that misinterpret Section 4.2.2.17 of [RFC1122] may fall victim to DoS attacks by not supporting sufficient mechanisms to allow release of system resources tied up by connections in the persist condition during times of resource exhaustion. For example, take the case of a busy server where multiple (attacker) clients can advertise a zero window forever (by reliably acknowledging the ZWPs). This could eventually lead to resource exhaustion in the server system. In such cases, the application or operating system would need to take appropriate action on the TCP connection to reclaim their resources and continue to maintain legitimate connections.
ただし、[RFC1122]のセクション4.2.2.17を誤って解釈するシステムがリソースの枯渇の時間の間に持続状態で接続によって縛られ、システムリソースの解放を可能にするのに十分なメカニズムをサポートしていないことにより、DoS攻撃の犠牲になることがあります。例えば、複数の（攻撃者）クライアントは（確実にZWPsを認めることで）永久にゼロウィンドウを宣伝することができます忙しいサーバーのケースを取ります。これは、最終的にはサーバシステムに枯渇資源化につながる可能性があります。このような場合には、アプリケーションやオペレーティング・システムは、そのリソースを再利用して、正当な接続を維持し続けるためにTCPコネクション上の適切な行動を取る必要があります。
The problem is applicable to TCP and TCP-derived flow-controlled transport protocols such as the Stream Control Transmission Protocol (SCTP).
問題は、ストリーム制御伝送プロトコル（SCTP）としてTCPとTCP由来フロー制御トランスポートプロトコルにも適用可能です。
Clearly, a system needs to be robust to such attacks and allow connections in the persist condition to be aborted in the same way as any other connection. Section 4 of this document provides the requisite clarification to permit such resource management.
明らかに、このシステムは、このような攻撃に堅牢でかつ持続状態での接続が他の接続と同じように中止することができるようにする必要があります。このドキュメントのセクション4は、このようなリソース管理を可能にするために必要な明確化を提供します。
To illustrate a potential DoS scenario, consider the case where many client applications open TCP connections with an HTTP [RFC2616] server, and each sends a GET request for a large page and stops reading the response partway through. This causes the client's TCP implementation to advertise a zero window to the server. For every large HTTP response, the server is left holding on to the response data in its sending queue. The amount of response data held will depend on the size of the send buffer and the advertised window. If the clients never read the data in their receive queues and therefore do not clear the persist condition, the server will continue to hold that data indefinitely. Since there may be a limit to the operating system kernel memory available for TCP buffers, this may result in DoS to legitimate connections by locking up the necessary resources. If the above scenario persists for an extended period of time, it will lead to starvation of TCP buffers and connection blocks, causing legitimate existing connections and new connection attempts to fail.
潜在的なDoS攻撃のシナリオを説明するために、多くのクライアント・アプリケーションのオープンTCPのHTTP [RFC2616]サーバとの接続、およびそれぞれが大きなページに対するGETリクエストを送信し、途中で応答を読んで停止した場合を考えます。これは、サーバーにゼロウィンドウを宣伝するために、クライアントのTCP実装の原因となります。すべての大規模なHTTP応答のために、サーバーは、その送信キューの応答データに握っ残されています。保持された応答データ量が送信バッファのサイズと広告ウィンドウに依存するであろう。クライアントが存続の条件をクリアしていないため、その受信キュー内のデータを読み、決して場合は、サーバーは無期限にそのデータを保持し続けます。 TCPバッファの利用可能なオペレーティングシステムカーネルメモリに限界があるかもしれないので、これは必要なリソースをロックすることにより、正当な接続に対してDoS攻撃をもたらすことができます。上記のシナリオが長時間続く場合は、それが正当な既存の接続と失敗する新しい接続試行を引き起こし、TCPバッファと接続ブロックの飢餓につながります。
A clever application needs to detect such attacks with connections that are not making progress, and could close these connections.
巧妙なアプリケーションが進展していない接続で、このような攻撃を検出する必要があり、これらの接続を閉じることができます。
However, some applications might have transferred all the data to the TCP socket and subsequently closed the socket, leaving the connections with no controlling process; such connections are referred to as orphaned connections. These orphaned connections might be left holding the data indefinitely in their sending queue.
ただし、一部のアプリケーションは、TCPソケットにすべてのデータを転送している場合があります、その後、無制御プロセスとの接続を残して、ソケットを閉じました。そのような接続は、孤立した接続と呼ばれます。これらの孤立した接続は、その送信キューに無期限にデータを保持しておくことがあります。
The US Computer Emergency Readiness Team (CERT) has released an advisory in this regard [VU723308] and is making vendors aware of this DoS scenario.
米国のコンピュータ緊急対応チーム（CERT）は、この点について[VU723308]で助言をリリースしましたし、このDoS攻撃のシナリオを意識ベンダーを作っています。
As stated in [RFC1122], a TCP implementation MUST NOT close a connection merely because it seems to be stuck in the ZWP or persist condition. Though unstated in RFC 1122, but implicit for system robustness, a TCP implementation needs to allow connections in the ZWP or persist condition to be closed or aborted by their applications or other resource management routines in the operating system.
[RFC1122]で述べたように、ZWPで立ち往生や状態を持続しているように見えるので、TCPの実装は、単に接続を閉じてはなりません。 RFC 1122での暗黙のが、システムの堅牢性の暗黙的なものの、TCPの実装はZWPで接続を許可するか、オペレーティングシステムでのアプリケーションや他のリソース管理ルーチンによって閉じたり中止されるべき状態を永続化する必要があります。
An interface that allows an application to inform TCP on what to do when the connection stays in the persist condition, or that allows an application or other resource manager to query the health of the TCP connection, is considered outside the scope of this document. All such techniques, however, are in complete compliance with TCP [RFC0793] and [RFC1122].
アプリケーションは、接続が持続した状態にとどまり、またはそれはアプリケーションや他のリソースマネージャは、TCPコネクションの状態を照会することができたときに何をすべきかにTCPを通知することを可能にするインターフェースは、この文書の範囲外と考えられています。すべてのこのような技術は、しかし、TCP [RFC0793]と[RFC1122]で完全に準拠しています。
This document discusses one system security consideration that is listed in "Guidelines for Writing RFC Text on Security Considerations" [RFC3552]. In particular, it describes an inappropriate use of a system that is acting as a server for many users. That use and a possible DoS attack are discussed in Section 3.
この文書では、「セキュリティの考慮事項の書き方RFCテキストのためのガイドライン」[RFC3552]にリストされている1システムセキュリティ検討について説明します。特に、多くのユーザーのためのサーバとして動作しているシステムの不適切な使用を記載しています。それを使用し、可能なDoS攻撃は、第3節で議論されています。
This document limits itself to clarifying RFC 1122. It does not discuss what can happen with orphaned connections and other possible mitigation techniques, as these are considered outside the scope of this document.
この文書では、それはこれらは、このドキュメントの範囲外と見なされるように、孤立した接続および他の可能な緩和技術で何が起こるかについては説明しませんRFC 1122を明確に自分自身を制限します。
This document was inspired by the recent discussions that took place regarding the TCP persist condition issue in the TCP Maintenance and Minor Extensions (TCPM) Working Group mailing list [TCPM]. The outcome of those discussions was to come up with a document that would clarify the intentions of the ZWP as discussed in RFC 1122. We
この文書は、[TCPM] TCPメンテナンスとマイナーExtensionsの条件の問題（TCPM）ワーキンググループのメーリングリストを持続TCPに関して行われた最近の議論に触発されました。 RFC 1122私たちに説明したように、これらの議論の結果は、ZWPの意図を明確になり、文書を考え出すことでした
would like to thank Mark Allman, Ted Faber, and David Borman for clarifying the objective behind this document. Thanks also go to Wesley Eddy for his extensive editorial comments and to Dan Wing, Mark Allman, and Fernando Gont for providing feedback on this document.
このドキュメントの後ろの目的を明確にするために、マークオールマン、テッドフェーバー、とDavidボーマンに感謝したいと思います。おかげでもこのドキュメントに関するフィードバックを提供するために彼の豊富な編集上のコメントのためにとダン・ウィング、マーク・オールマン、そしてフェルナンドGontにウェズリー渦に行きます。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[TCPM] IETF, "TCP Maintenance and Minor Extensions (tcpm) - Charter", <http://datatracker.ietf.org/wg/tcpm/charter/>.
[TCPM] IETF、 "TCPメンテナンスとマイナー拡張機能（tcpm） - 憲章"、<http://datatracker.ietf.org/wg/tcpm/charter/>。
[VU723308] Manion, A. and D. Warren, "TCP may keep its offered receive window closed indefinitely (RFC 1122)", November 2009, <http://www.kb.cert.org/vuls/id/723308>.
[VU723308] Manion、A.とD.ウォーレンは、 "TCPキープもその受信提供ウィンドウ無期限閉鎖さ（RFC 1122）"、2009年11月、<http://www.kb.cert.org/vuls/id/723308> 。
Authors' Addresses
著者のアドレス
Murali Bashyam Ocarina Networks, Inc. 42 Airport Parkway San Jose, CA 95110 USA
ファイフBSYँオカリナネットワーク、これ。 42空港パークウェイサンノゼ、95110それ
Phone: +1 (408) 512-2966 EMail: mbashyam@ocarinanetworks.com
電話：+1（408）512-2966 Eメール：mbashyam@ocarinanetworks.com
Mahesh Jethanandani Cisco 170 Tasman Drive San Jose, CA 95134 USA
マヘシュJethanandaniシスコ170タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 (408) 527-8230 EMail: mjethanandani@gmail.com
電話：+1（408）527-8230 Eメール：mjethanandani@gmail.com
Anantha Ramaiah Cisco 170 Tasman Drive San Jose, CA 95134 USA
Anantha Ramaiahシスコ170タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 (408) 525-6486 EMail: ananth@cisco.com
電話：+1（408）525-6486 Eメール：ananth@cisco.com