RFC 6429 - TCP Sender Clarification for Persist Condition 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6429
タイトル : RFC 6429 - 永続的な状態のためのTCP送信者の明確化
翻訳編集 : 自動生成

[要約] RFC 6429は、TCPの送信者がPersist状態にある場合の動作を明確化するためのものです。その目的は、Persist状態にあるTCPセッションのパフォーマンスを向上させることです。

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

永続的な状態のためのTCP送信者の明確化

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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6429で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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

1. Introduction

1. はじめに

Section 4.2.2.17 of "Requirements for Internet Hosts -- Communication Layers" [RFC1122] says:

「インターネットホストの要件 - 通信レイヤー」[RFC1122]のセクション4.2.2.17は次のように述べています。

"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は、提供された受信ウィンドウを無期限に閉じたままにすることができます。受信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要件に対する要件言語の明確化で締めくくります。

1.1. Requirements Language

1.1. 要件言語

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].

キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、[RFC2119]に記載されているように解釈されます。

2. Discussion of RFC 1122 Requirement

2. RFC 1122要件の議論

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攻撃の犠牲になる可能性があります。たとえば、複数の（攻撃者）クライアントがゼロウィンドウを永久に宣伝できる（ZWPを確実に認めることにより）、忙しいサーバーのケースを取り上げます。これにより、最終的にサーバーシステムのリソースの疲労が生じる可能性があります。そのような場合、アプリケーションまたはオペレーティングシステムは、TCP接続に対して適切なアクションを実行して、リソースを回収し、合法的な接続を維持し続ける必要があります。

The problem is applicable to TCP and TCP-derived flow-controlled transport protocols such as the Stream Control Transmission Protocol (SCTP).

この問題は、TCPおよびTCP由来のフロー制御輸送プロトコルに適用されます。ストリーム制御伝送プロトコル（SCTP）などです。

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では、そのようなリソース管理を許可するために必要な明確化を提供します。

3. Description of One Simple Attack

3. 1つの単純な攻撃の説明

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シナリオを説明するために、多くのクライアントアプリケーションがHTTP [RFC2616]サーバーでTCP接続を開く場合を検討し、それぞれが大きなページのGETリクエストを送信し、途中で応答の読み取りを停止します。これにより、クライアントのTCP実装により、ゼロウィンドウをサーバーに宣伝します。大規模なHTTP応答ごとに、サーバーは送信キューの応答データを保持しています。保持されている応答データの量は、送信バッファーのサイズと広告ウィンドウに依存します。クライアントが受信キューのデータを読み取らず、したがって永続的な状態をクリアしない場合、サーバーはそのデータを無期限に保持し続けます。 TCPバッファーで利用可能なオペレーティングシステムカーネルメモリに制限がある可能性があるため、これにより、必要なリソースをロックすることでDOSが正当な接続になる可能性があります。上記のシナリオが長期間持続している場合、TCPバッファーと接続ブロックの飢starにつながり、正当な既存の接続と新しい接続の試みが失敗します。

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.

米国のコンピューターEmergency Readinessチーム（CERT）は、この点でアドバイザリーをリリースし[VU723308]、このDOSシナリオをベンダーに認識させています。

4. Clarification Regarding RFC 1122 Requirements

4. RFC 1122要件に関する明確化

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]に記載されているように、TCPの実装は、ZWPまたは持続条件に閉じ込められているように見えるという理由だけで、接続を閉じてはなりません。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]に完全に準拠しています。

5. Security Considerations

5. セキュリティに関する考慮事項

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を明確にすることに制限されています。これらは、このドキュメントの範囲外であると見なされるため、孤立した接続や他の緩和手法で何が起こるかについては説明しません。

6. Acknowledgments

6. 謝辞

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

このドキュメントは、TCPメンテナンスおよびマイナーエクステンション（TCPM）ワーキンググループメーリングリスト[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.

この文書の背後にある目標を明確にしてくれたマーク・オールマン、テッド・フェイバー、デビッド・ボーマンに感謝したいと思います。また、彼の広範な編集コメントをしてくれたWesley Eddyと、このドキュメントに関するフィードバックを提供してくれたDan Wing、Mark Allman、Fernando Gontにも感謝します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

7.2. Informative References

7.2. 参考引用

[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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。

[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.

[RFC4732] Handley、M.、Ed。、Rescorla、E.、ed。、および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]マニオン、A。およびD.ウォーレン、「TCPは、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

Murali Bashyam Ocarina Networks、Inc。42 Airport Parkway San Jose、CA 95110 USA

   Phone: +1 (408) 512-2966
   EMail: mbashyam@ocarinanetworks.com

Mahesh Jethanandani Cisco 170 Tasman Drive San Jose, CA 95134 USA

Mahesh Jethanandani Cisco 170 Tasman Drive San Jose、CA 95134 USA

   Phone: +1 (408) 527-8230
   EMail: mjethanandani@gmail.com

Anantha Ramaiah Cisco 170 Tasman Drive San Jose, CA 95134 USA

アナンサラマイアシスコ170タスマンドライブサンノゼ、カリフォルニア95134 USA

   Phone: +1 (408) 525-6486
   EMail: ananth@cisco.com