RFC 6191 - Reducing the TIME-WAIT State Using TCP Timestamps 日本語訳

URL : https://tools.ietf.org/html/rfc6191
タイトル : RFC 6191 - TCPタイムスタンプを使用してTIME-WAIT状態の削減
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 6191                                       UK CPNI
BCP: 159                                                      April 2011
Category: Best Current Practice
ISSN: 2070-1721

           Reducing the TIME-WAIT State Using TCP Timestamps

Abstract

抽象

This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged.

この文書では、TCPタイムスタンプオプションは、着信SYNセグメント中に存在する場合、任意の2つのTCPエンドポイントとの間の高いコネクション確立レートを可能にする着信SYNセグメントを処理するためのアルゴリズムを記載しています。この文書は、TIME-WAIT状態にある接続のために受信SYNセグメントの処理を変更します。他のすべての州での処理は変更されません。

Status of This Memo

このメモのステータス

This memo documents an Internet Best Current Practice.

このメモはインターネット最も良い現在の練習を説明します。

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). Further information on BCPs is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、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/rfc6191.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6191で取得することができます。

著作権表示

著作権（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ライセンスのテキストを含める必要があり、この文書から抽出されました。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Improved Processing of Incoming Connection Requests  . . . . .  3
   3.  Interaction with Various Timestamp Generation Algorithms . . .  6
   4.  Interaction with Various ISN Generation Algorithms . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Behavior of the Proposed Mechanism in Specific
                Scenarios . . . . . . . . . . . . . . . . . . . . . . 10
     A.1.  Connection Request after System Reboot . . . . . . . . . . 10

1. Introduction

1. はじめに

The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP to include a timestamp value in its segments that can be used to perform two functions: Round-Trip Time Measurement (RTTM) and Protection Against Wrapped Sequences (PAWS).

時間計測（RTTM）とに対する保護ラップ配列（PAWS）を往復：RFC 1323 [RFC1323]で指定されたタイムスタンプオプションは、TCPは、2つの機能を実行するために使用することができ、そのセグメント内のタイムスタンプ値を含むことができます。

For the purpose of PAWS, the timestamps sent on a connection are required to be monotonically increasing. While there is no requirement that timestamps are monotonically increasing across TCP connections, the generation of timestamps such that they are monotonically increasing across connections between the same two endpoints allows the use of timestamps for improving the handling of SYN segments that are received while the corresponding four-tuple is in the TIME-WAIT state. That is, the Timestamps option could be used to perform heuristics to determine whether to allow the creation of a new incarnation of a connection that is in the TIME-WAIT state.

PAWSの目的のために、接続上で送信されたタイムスタンプが単調に増加することが要求されます。タイムスタンプは、単調にTCP接続を横切って増加しているという要件はないが、それらは単調に同じ2つのエンドポイント間の接続を横切って増加しているようなタイムスタンプの生成は、対応する4つの間に受信されたSYNセグメントの取り扱いを改善するためのタイムスタンプの使用を可能にしますタプルはTIME-WAIT状態にあります。これは、タイムスタンプオプションがTIME-WAIT状態にある接続の新しい化身の作成を許可するかどうかを判断するヒューリスティックを実行するために使用することができています。

This use of TCP timestamps is simply an extrapolation of the use of Initial Sequence Numbers (ISNs) for the same purpose, as allowed by RFC 1122 [RFC1122], and it has been incorporated in a number of TCP implementations, such as that included in the Linux kernel [Linux].

[RFC1122] RFC 1122によって許容されるようTCPタイムスタンプの使用は、単に同じ目的のための初期シーケンス番号（ISNの）の使用の外挿であり、それはそのような中に含まれるような、TCP実装の数に組み込まれていますLinuxカーネル[Linuxの]。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

2. Improved Processing of Incoming Connection Requests

着信接続要求の2改善された加工

In a number of scenarios, a socket pair may need to be reused while the corresponding four-tuple is still in the TIME-WAIT state in a remote TCP peer. For example, a client accessing some service on a host may try to create a new incarnation of a previous connection, while the corresponding four-tuple is still in the TIME-WAIT state at the remote TCP peer (the server). This may happen if the ephemeral port numbers are being reused too quickly, either because of a bad policy of selection of ephemeral ports, or simply because of a high connection rate to the corresponding service. In such scenarios, the establishment of new connections that reuse a four-tuple that is in the TIME-WAIT state would fail. This problem is discussed in detail in [INFOCOM-99].

対応する4つのタプルがリモートTCPピアにTIME-WAIT状態にある間シナリオの数が、ソケットペアを再使用する必要があるかもしれません。たとえば、ホスト上のいくつかのサービスにアクセスするクライアントは、対応する4つのタプルがリモートTCPピア（サーバー）でTIME-WAIT状態にある間に、前の接続の新しいインカネーションを作成しようとします。一時ポート番号があまりにも速く、いずれかのために、または単にので、対応するサービスへの高い接続率のエフェメラルポートの選択の悪い政策の再利用されている場合に発生します。このようなシナリオでは、TIME-WAIT状態にある4つのタプルを再利用し、新しい接続の確立は失敗します。この問題は、[INFOCOM-99]で詳細に説明されています。

In order to avoid this problem, Section 4.2.2.13 of RFC 1122 [RFC1122] states that when a connection request is received with a four-tuple that is in the TIME-WAIT state, the connection request may be accepted if the sequence number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for that direction of the data transfer). The goal of this requirement is to prevent the overlap of the sequence number spaces of the old and new incarnations of the connection so that segments from the old incarnation are not accepted as valid by the new incarnation.

この問題を回避するために、RFC 1122 [RFC1122]のセクション4.2.2.13は、接続要求がTIME-WAIT状態にある四つ組で受信されたときに、接続要求が受け入れられると述べている場合のシーケンス番号着信SYNセグメントは、（データ転送の方向のために）接続の前の化身に見られる最後のシーケンス番号よりも大きいです。この要件の目的は、古い化身からのセグメントが新しいインカネーションで有効なものとして受け入れられないように、接続の古いものと新しい化身のシーケンス番号空間の重複を防ぐためです。

The same policy may be extrapolated to TCP timestamps. That is, when a connection request is received with a four-tuple that is in the TIME-WAIT state, the connection request could be accepted if the timestamp of the incoming SYN segment is greater than the last timestamp seen on the previous incarnation of the connection (for that direction of the data transfer).

同じポリシーは、TCPタイムスタンプに外挿することができます。すなわち、接続要求がTIME-WAIT状態にある四つ組で受信されたときに、着信SYNセグメントのタイムスタンプが以前の化身で見られる最後のタイムスタンプよりも大きい場合には、接続要求を受け付けることができ、あります（データ転送の方向のための）接続。

The following paragraphs summarize the processing of SYN segments received for connections in the TIME-WAIT state. The processing of SYN segments received for connections in all other states is unchanged. Both the ISN (Initial Sequence Number) and the Timestamps option (if present) of the incoming SYN segment are included in the heuristics performed for allowing a high connection-establishment rate.

以下の段落では、SYNセグメントの処理はTIME-WAIT状態にある接続のために受信された要約します。全ての他の状態に接続するために受信されたSYNセグメントの処理は不変です。 ISN（初期シーケンス番号）と着信SYNセグメントのタイムスタンプオプション（存在する場合）の両方が高いコネクション確立レートを可能にするために行わヒューリスティックに含まれています。

Processing of SYN segments received for connections in the TIME-WAIT state SHOULD occur as follows:

SYNセグメントの処理は次のように行われるべきTIME-WAIT状態にある接続のために受信しました：

o If the previous incarnation of the connection used Timestamps, then:

Oコネクションの前の化身はその後、タイムスタンプを使用した場合：

* If TCP Timestamps would be enabled for the new incarnation of the connection, and the timestamp contained in the incoming SYN segment is greater than the last timestamp seen on the previous incarnation of the connection (for that direction of the data transfer), honor the connection request (creating a connection in the SYN-RECEIVED state).

* TCPタイムスタンプが接続の新しい化身のために有効に、着信SYNセグメントに含まれるタイムスタンプは（データ転送の方向のために）接続の前の化身に見られる最後のタイムスタンプよりも大きい、尊重されることになる場合接続要求（SYN-受信した状態で接続を作成します）。

* If TCP Timestamps would be enabled for the new incarnation of the connection, the timestamp contained in the incoming SYN segment is equal to the last timestamp seen on the previous incarnation of the connection (for that direction of the data transfer), and the Sequence Number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for that direction of the data transfer), honor the connection request (creating a connection in the SYN-RECEIVED state).

TCPタイムスタンプが接続の新しい化身のために有効にされる場合*、受信SYNセグメントに含まれるタイムスタンプは、（データ転送の方向のために）接続の前の化身で見られる最後のタイムスタンプに等しく、シーケンス受信SYNセグメントの数は、（データ転送の方向のために）接続の前の化身に見られる最後のシーケンス番号よりも大きい場合、接続要求（SYN-受信した状態で接続を作成する）を称えます。

* If TCP Timestamps would not be enabled for the new incarnation of the connection, but the Sequence Number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer), honor the connection request (creating a connection in the SYN-RECEIVED state).

* TCPタイムスタンプは、接続の新しい化身のために有効にされないだろうが、受信SYNセグメントのシーケンス番号は（データ転送の同方向の場合）接続の前の化身に見られる最後のシーケンス番号よりも大きい場合、接続要求（SYN-受信した状態で接続を作成する）を称えます。

* Otherwise, silently drop the incoming SYN segment, thus leaving the previous incarnation of the connection in the TIME-WAIT state.

*そうでない場合は、サイレント従ってTIME-WAIT状態で接続の前の化身を残し、受信SYNセグメントをドロップ。

o If the previous incarnation of the connection did not use Timestamps, then:

Oコネクションの前の化身はその後、タイムスタンプを使用しなかった場合：

* If TCP Timestamps would be enabled for the new incarnation of the connection, honor the incoming connection request (creating a connection in the SYN-RECEIVED state).

* TCPタイムスタンプは、接続の新しいインカネーションのために有効にされるだろう場合は、着信接続要求（SYN-RECEIVED状態の接続を作成する）を称えます。

* If TCP Timestamps would not be enabled for the new incarnation of the connection, but the Sequence Number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer), honor the incoming connection request (creating a connection in the SYN-RECEIVED state).

* TCPタイムスタンプは、接続の新しい化身のために有効にされないだろうが、受信SYNセグメントのシーケンス番号は（データ転送の同方向の場合）接続の前の化身に見られる最後のシーケンス番号よりも大きい場合着信接続要求（SYN-受信した状態で接続を作成する）を称えます。

* Otherwise, silently drop the incoming SYN segment, thus leaving the previous incarnation of the connection in the TIME-WAIT state.

*そうでない場合は、サイレント従ってTIME-WAIT状態で接続の前の化身を残し、受信SYNセグメントをドロップ。

Note:

注意：

In the above explanation, the phrase "TCP Timestamps would be enabled for the new incarnation for the connection" means that the incoming SYN segment contains a TCP Timestamps option (i.e., the client has enabled TCP Timestamps), and that the SYN/ACK segment that would be sent in response to it would also contain a Timestamps option (i.e., the server has enabled TCP Timestamps). In such a scenario, TCP Timestamps would be enabled for the new incarnation of the connection.

上記の説明では、語句「TCPタイムスタンプは、接続のための新しいインカネーションのために有効にされるだろう」、着信SYNセグメントはTCPタイムスタンプオプションが含まれている（つまり、クライアントはTCPタイムスタンプを有効にしている）、およびSYN / ACKセグメントということを意味しそれは、それはまた（すなわち、サーバはTCPタイムスタンプを有効にしている）タイムスタンプオプションが含まれますに応じて送信されます。このようなシナリオでは、TCPタイムスタンプは、接続の新しいインカネーションのために有効にされるだろう。

The "last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer)" refers to the last sequence number used by the previous incarnation of the connection (for the same direction of the data transfer), and not to the last value seen in the Sequence Number field of the corresponding segments. That is, it refers to the sequence number corresponding to the FIN flag of the previous incarnation of the connection, for that direction of the data transfer.

「（データ転送の同方向の場合）接続の前の化身に見られる最後のシーケンス番号」は、（データ転送の同方向の場合）接続の前の化身で使用される最後のシーケンス番号を参照してない対応するセグメントのシーケンス番号フィールドで見られる最後の値に。つまり、データ転送の方向のために、接続の前の化身のFINフラグに対応するシーケンス番号を指す、です。

Many implementations do not include the TCP Timestamps option when performing the above heuristics, thus imposing stricter constraints on the generation of Initial Sequence Numbers, the average data transfer rate of the connections, and the amount of data transferred with them. RFC 793 [RFC0793] states that the ISN generator should be incremented roughly once every four microseconds (i.e., roughly 250,000 times per second). As a result, any connection that transfers more than 250,000 bytes of data at more than 250 kilobytes/ second could lead to scenarios in which the last sequence number seen on a connection that moves into the TIME-WAIT state is still greater than the sequence number of an incoming SYN segment that aims at creating a new incarnation of the same connection. In those scenarios, the ISN heuristics would fail, and therefore the connection request would usually time out. By including the TCP Timestamps option in the heuristics described above, all these constraints are greatly relaxed.

上記のヒューリスティックを実行するときに多くの実装では、このように初期シーケンス番号の生成に厳しい制約、接続の平均データ転送速度、およびそれらと転送されるデータの量を課す、TCPタイムスタンプオプションが含まれていません。 RFC 793 [RFC0793]はISN発生器はおおよそ一度4マイクロ秒（即ち、おおよそ25万回毎秒）インクリメントされるべきであると述べています。結果として、より250キロバイト/秒でのデータの25万の以上のバイトを転送する任意の接続は、TIME-WAIT状態に移行接続で見られる最後のシーケンス番号がまだシーケンス番号よりも大きいシナリオにつながる可能性同じ接続の新しい化身を作成することを目的と受信SYNセグメントの。これらのシナリオでは、ISNヒューリスティックは失敗し、そのための接続要求は、通常はタイムアウトします。上記の経験則でTCPタイムスタンプオプションを含めることにより、これらすべての制約が大幅に緩和されています。

It is clear that the use of TCP timestamps for the heuristics described above benefit from timestamps that are monotonically increasing across connections between the same two TCP endpoints.

タイムスタンプから利益上述ヒューリスティックのTCPタイムスタンプの使用は単調に同一の2つのTCPエンドポイント間の接続を横切って増加していることは明らかです。

Note: The upcoming revision of RFC 1323, [1323bis], recommends the selection of timestamps such that they are monotonically increasing across connections. An example of such a timestamp generation scheme can be found in [TS-Generation].

注：RFC 1323の今後の改正、[1323bis]は、彼らが単調に接続間で増加していることを、このようなタイムスタンプの選択を推奨しています。このようなタイムスタンプ生成スキームの例は、[TS-生成]に見出すことができます。

3. Interaction with Various Timestamp Generation Algorithms

様々なタイムスタンプ生成アルゴリズム3.相互作用

The algorithm proposed in Section 2 clearly benefits from timestamps that are monotonically increasing across connections to the same endpoint. In particular, generation of timestamps such that they are monotonically increasing is important for TCP instances that perform the active open, as those are the timestamps that will be used for the proposed algorithm.

第2節で提案したアルゴリズムは明らかに単調に同じエンドポイントに接続間で増加しているタイムスタンプから利益を得ます。それらは、提案されたアルゴリズムに使用されるタイムスタンプであるように、特に、それらが単調増加しているように、タイムスタンプの生成は、アクティブオープンを行うTCPインスタンスのために重要です。

While monotonically increasing timestamps ensure that the proposed algorithm will be able to reduce the TIME-WAIT state of a previous incarnation of a connection, implementation of the algorithm (by itself) does not imply a requirement on the timestamp generation algorithm of other TCP implementations.

単調に増加するタイムスタンプが提案されたアルゴリズムは、接続の前の化身のTIME-WAIT状態を軽減することができるであろうことを保証しながら、（それ自体で）アルゴリズムの実装は、他のTCP実装のタイムスタンプ生成アルゴリズム上の要件を意味するものではありません。

In the worst-case scenario, an incoming SYN corresponding to a new incarnation of a connection in the TIME-WAIT contains a timestamp that is smaller than the last timestamp seen on the previous incarnation of the connection, the heuristics fail, and the result is no worse than the current state of affairs. That is, the SYN segment is ignored (as specified in [RFC1337]), and thus the connection request times out, or is accepted after future retransmissions of the SYN.

最悪のシナリオでは、TIME-WAITで接続の新しい化身に対応する着信SYNが接続の前化身で見られる最後のタイムスタンプよりも小さくなっているタイムスタンプが含まれ、ヒューリスティックは失敗し、その結果であります事務の現在の状態よりも悪化していません。すなわち、SYNセグメントは、（[RFC1337]で指定されるように）無視され、したがって、接続要求がタイムアウト、又はSYNの将来の再送信の後に受け入れられているされています。

Some stacks may implement timestamp generation algorithms that do not lead to monotonically increasing timestamps across connections with the same remote endpoint. An example of such algorithms is the one described in [RFC4987] and [Opperman], which allows the implementation of extended TCP SYN cookies.

いくつかのスタックが単調に同じリモートエンドポイントとの接続にわたってタイムスタンプの向上につながらないタイムスタンプ生成アルゴリズムを実装することができます。そのようなアルゴリズムの一例は、拡張TCP SYNクッキーの実装を可能にする[RFC4987]及び[Oppermanの]に記載のものです。

Note: It should be noted that the "extended TCP SYN cookies" could coexist with an algorithm for generating timestamps such that they are monotonically increasing. Monotonically increasing timestamps could be generated for TCP instances that perform the active open, while timestamps for TCP instances that perform the passive open could be generated according to [Opperman].

注：彼らが単調に増加していることを、このようなタイムスタンプを生成するためのアルゴリズムと共存させることができ、「拡張TCP SYNクッキー」ことに留意すべきです。パッシブオープンを行うTCPインスタンスのタイムスタンプは[Oppermanの】に従って生成することができるが単調に増加するタイムスタンプは、アクティブオープンを行うTCPインスタンスのために生成することができます。

Some stacks (notably OpenBSD) implement timestamp randomization algorithms which do not result in monotonically increasing ISNs across connections. As noted in [Silbersack], such randomization schemes may prevent the mechanism proposed in this document from recycling connections that are in the TIME-WAIT state. However, as noted earlier in this section in the worst-case scenario, the heuristics fail, and the result is no worse than the current state of affairs.

いくつかのスタック（特にOpenBSDは）単調に接続にわたってISNが増加をもたらさないタイムスタンプランダム化アルゴリズムを実装しています。【Silbersack]で述べたように、そのようなランダム化スキームは、TIME-WAIT状態にある接続をリサイクルから本書で提案されたメカニズムを防止することができます。しかし、最悪のシナリオでは、以前、このセクションで述べたように、ヒューリスティックは失敗し、その結果が現在の状況よりも悪化していません。

4. Interaction with Various ISN Generation Algorithms

種々ISN生成アルゴリズム4.インタラクション

[RFC0793] suggests that the ISNs of TCP connections be generated from a global timer, such that they are monotonically increasing across connections. However, this ISN-generation scheme leads to predictable ISNs, which have well-known security implications [CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme that results in monotonically increasing ISNs across connections that are not easily predictable by an off-path attacker.

[RFC0793]はTCPコネクションのISNを、彼らが単調に接続間で増加しているように、グローバルタイマーから生成することを示唆しています。しかし、このISN世代方式は、よく知られたセキュリティへの影響[CPNI-TCP]を持って予測可能なのISNにつながります。 [RFC1948]は単調オフパス攻撃者によって容易に予測されない接続でISNが増加をもたらす代替ISN-生成方式を提案します。

Some stacks (notably OpenBSD) implement ISN randomization algorithms which do not result in monotonically increasing ISNs across connections. As noted in [Silbersack], such ISN randomization schemes break BSD's improved handling of SYN segments received for connections that are in the TIME-WAIT state.

いくつかのスタック（特にOpenBSDは）単調に接続にわたってISNが増加をもたらさないISNのランダム化アルゴリズムを実装しています。【Silbersack]で述べたように、このようなISNランダム化スキームは、SYNセグメントのBSDの改善されたハンドリングはTIME-WAIT状態にある接続のために受信破ります。

An implementation of the mechanism proposed in this document would enable recycling of the TIME-WAIT state even in the presence of ISNs that are not monotonically increasing across connections, except when the timestamp contained in the incoming SYN is equal to the last timestamp seen on the connection in the TIME-WAIT state (for that direction of the data transfer).

この文書で提案されたメカニズムの実装も単調着信SYNに含まれるタイムスタンプがで見られる最後のタイムスタンプと同じである場合を除いて、接続を横切って増加していないISNの存在下で、TIME-WAIT状態のリサイクルを可能にします（データ転送の方向に対して）TIME-WAIT状態で接続。

5. Security Considerations

5.セキュリティについての考慮事項

[TCP-Security] contains a detailed discussion of the security implications of TCP Timestamps and of different timestamp generation algorithms.

[TCP-セキュリティ] TCPタイムスタンプのと異なるタイムスタンプ生成アルゴリズムのセキュリティへの影響の詳細な議論が含まれています。

6. Acknowledgements

6.謝辞

This document is based on part of the contents of the technical report "Security Assessment of the Transmission Control Protocol (TCP)" [CPNI-TCP] written by Fernando Gont on behalf of the United Kingdom's Centre for the Protection of National Infrastructure (UK CPNI).

この文書は、英国CPNI（技術報告書国家インフラの保護のためのイギリスのセンターに代わってフェルナンドGontによって書かれた[CPNI-TCP]「伝送制御プロトコル（TCP）のセキュリティ評価」の内容の一部に基づいています）。

The author of this document would like to thank (in alphabetical order) Mark Allman, Francis Dupont, Wesley Eddy, Lars Eggert, John Heffner, Alfred Hoenes, Christian Huitema, Eric Rescorla, Joe Touch, and Alexander Zimmermann for providing valuable feedback on an earlier version of this document.

本書の著者は、上の貴重なフィードバックを提供するために（アルファベット順に）感謝するマーク・オールマン、フランシスデュポン、ウェズリーエディ、ラースEggertの、ジョンHeffner、アルフレッドHoenes、クリスチャンのHuitema、エリックレスコラ、ジョー・タッチ、アレクサンドル・ツィンマーマンをしたいと思いますこのドキュメントの以前のバージョン。

Additionally, the author would like to thank David Borman for a fruitful discussion on TCP Timestamps at IETF 73.

さらに、著者はIETF 73でTCPタイムスタンプに実りある議論のためのデビッド・ボーマンに感謝したいと思います。

Finally, the author would like to thank the United Kingdom's Centre for the Protection of National Infrastructure (UK CPNI) for their continued support.

最後に、著者は彼らの継続的な支援のための国家インフラの保護のためのイギリスのセンター（UK CPNI）を感謝したいと思います。

Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.

IETFミーティングにフェルナンドGontの出席は、ISOCのプログラム「フェローシップIETFへ」によってサポートされていました。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

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

[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。

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

[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。

[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[RFC1323]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。

[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月。

7.2. Informative References

7.2. 参考文献

[1323bis] Borman, D., Braden, R., and V. Jacobson, "TCP Extensions for High Performance", Work in Progress, March 2009.

[1323bis]ボーマン、D.、ブレーデン、R.、およびV.ヤコブソン、 "ハイパフォーマンスのためのTCP拡張"、進歩、2009年3月での作業。

[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>.

[CPNI-TCP] CPNI、2009年、<http://www.cpni.gov.uk/Docs/ TN-03-09-セキュリティ・アセスメント・TCP.pdf "伝送制御プロトコル（TCP）のセキュリティ評価" >。

[INFOCOM-99] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 1999, pp. 1573-1583.

"ビジーサーバー上のTCPとその効果でTIME-WAIT状態" [インフォコム-99]フェーバー、T.、タッチ、J.、およびW.越、PROC。 IEEEインフォコム、1999頁。1573年から1583年。

[Linux] Linux Kernel Organization, "The Linux Kernel Archives", <http://www.kernel.org>.

[Linuxの] Linuxカーネルの組織、 "Linuxカーネルアーカイブ"、<http://www.kernel.org>。

[Opperman] Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD-current", post to the tcpm mailing list, September 2006, <http://www.ietf.org/mail-archive/ web/tcpm/current/msg02251.html>.

[Oppermanの] Oppermannの、A.、 "FYI：FreeBSDの電流での拡張のTCP syncookies機能"、tcpmメーリングリストに投稿し、2006年9月、<http://www.ietf.org/mail-archive/ウェブ/ tcpm /現在/msg02251.html>。

[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.

"TCPでのTIME-WAITの暗殺の危険" [RFC1337]ブレーデン、B.、RFC 1337、1992年5月。

[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.

[RFC1948] Bellovin氏、S.、 "シーケンス番号攻撃からの保護"、RFC 1948、1996年5月。

[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.

[RFC4987]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、RFC 4987、2007年8月。

[Silbersack] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005.

[Silbersack] Silbersack、M.、 "相互運用性を犠牲にすることなく、ランダム化を通じてTCP / IPセキュリティの改善"、EuroBSDCon 2005。

[TCP-Security] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, January 2011.

[TCP-セキュリティ] Gont、F.、進歩、2011年1月の作業 "伝送制御プロトコル（TCP）のセキュリティ評価"。

[TS-Generation] Gont, F. and A. Oppermann, "On the generation of TCP timestamps", Work in Progress, June 2010.

[TS-生成] Gont、F.およびA. Oppermannの、 "TCPタイムスタンプの生成について"、進歩、2010年6月に作業が。

Appendix A. Behavior of the Proposed Mechanism in Specific Scenarios

特定のシナリオで提案された機構の付録A.行動

A.1. Connection Request after System Reboot

A.1。システムの再起動後に接続要求

This section clarifies how this algorithm would operate in case a computer reboots, keeps the same IP address, loses memory of the previous timestamps, and then tries to reestablish a previous connection.

このセクションでは、このアルゴリズムは、コンピュータが再起動した場合に動作するかを明確に同じIPアドレスを保持し、前のタイムスタンプの記憶を失い、その後、以前の接続を再確立しようとします。

Firstly, as specified in [RFC0793], hosts must not establish new connections for a period of 2*MSL (Maximum Segment Lifetime) after they boot (this is the "quiet time" concept). As a result, in terms of specifications, this scenario should never occur.

まず、[RFC0793]で指定されるように、ホストは（これは「静かな時間」という概念である）、彼らが起動した後、2 * MSL（最大セグメントライフタイム）の期間、新しい接続を確立してはいけません。その結果、仕様の面で、このシナリオが発生することはありません。

If a host does not comply with the "quiet time concept", a connection request might be sent to a remote host while there is a previous incarnation of the same connection in the TIME-WAIT state at the remote host. In such a scenario, as a result of having lost memory of previous timestamps, the resulting timestamps might not be monotonically increasing, and hence the proposed algorithm might be unable to recycle the previous incarnation of the connection that is in the TIME-WAIT state. This case corresponds to the current state of affairs without the algorithm proposed in this document.

ホストは、「静かな時間概念」に準拠していない場合は、リモート・ホストでのTIME-WAIT状態で同じ接続の以前の化身があるが、接続要求をリモートホストに送信される可能性があります。そのようなシナリオでは、前のタイムスタンプの記憶を失った結果として、得られたタイムスタンプは、単調に増加されないことがあり、従って提案されたアルゴリズムは、TIME-WAIT状態にある接続の前の化身をリサイクルすることができないかもしれません。この場合は、この文書で提案されたアルゴリズムことなく業務の現在の状態に対応します。

Author's Address

著者のアドレス

Fernando Gont UK Centre for the Protection of National Infrastructure

国家インフラの保護のためのフェルナンドGont英国センター

EMail: fernando@gont.com.ar URI: http://www.cpni.gov.uk

電子メール：URI fernando@gont.com.ar：http://www.cpni.gov.uk