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

原文URL : https://datatracker.ietf.org/doc/html/rfc6191
タイトル : RFC 6191 - TCPタイムスタンプを使用して、タイムウェイト状態を削減します
翻訳編集 : 自動生成

[要約] RFC 6191は、TCPタイムスタンプを使用してTIME-WAIT状態を削減する方法について説明しています。このRFCの目的は、TCP接続の再利用を促進し、ネットワークのパフォーマンスを向上させることです。

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

TCPタイムスタンプを使用して、タイムウェイト状態を削減します

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セグメントを処理するためのアルゴリズムについて説明します。このドキュメントは、タイムウェイト状態の接続に対して受信した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.

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

著作権表示

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ライセンステキストを含める必要があります。

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.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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).

RFC 1323 [RFC1323]で指定されたタイムスタンプオプションにより、TCPは、ラウンドトリップ時間測定（RTTM）とラップシーケンス（PAWS）に対する保護の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つのエンドポイントが受信されるシンセグメントの取り扱いを改善するためのタイムスタンプを使用することができます。-Tupleは時間待合状態です。つまり、タイムスタンプオプションを使用して、ヒューリスティックを実行して、時間待合状態にある接続の新しい化身の作成を許可するかどうかを判断できます。

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

TCPタイムスタンプのこの使用は、RFC 1122 [RFC1122]で許可されているのと同じ目的での初期シーケンス数（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ピアの時間待機状態にあります。たとえば、ホストで何らかのサービスにアクセスするクライアントは、以前の接続の新しい化身を作成しようとする場合がありますが、対応する4タプルはまだリモートTCPピア（サーバー）の時間待機状態です。これは、一時的なポートの選択のポリシーが悪いため、または単に対応するサービスへの接続率が高いために、一時的なポート番号が速すぎる場合に再利用されている場合に発生する可能性があります。このようなシナリオでは、時間待合状態にある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 [RFC1122]は、タイムウェイト状態の4タプルで接続要求を受信した場合、シーケンス番号の場合に接続要求を受け入れることができると述べています。着信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タイムスタンプに外挿される可能性があります。つまり、時間待合状態の4タプルで接続要求を受信すると、着信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セグメントの処理を要約します。他のすべての状態で接続に対して受け取ったSynセグメントの処理は変更されていません。ISN（初期シーケンス番号）と、入ってくるSynセグメントのタイムスタンプオプション（存在する場合）の両方が、高い接続確立速度を可能にするために実行されるヒューリスティックに含まれています。

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

タイムウェイト状態の接続に対して受け取ったSynセグメントの処理は、次のように発生する必要があります。

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セグメントに含まれるタイムスタンプが接続の以前の化身で見られる最後のタイムスタンプよりも大きい場合（データ転送の方向）、接続を尊重しますリクエスト（同期状態で接続を作成する）。

* 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セグメントのうち、接続の以前の化身で見られる最後のシーケンス番号よりも大きい（データ転送の方向）、接続要求（シンレシーブ状態で接続の作成）を尊重します。

* 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セグメントのシーケンス番号は、接続の前の化身で見られる最後のシーケンス番号よりも大きい場合（データ転送の同じ方向に対して）、接続要求を尊重します（同期状態で接続を作成します）。

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

* それ以外の場合は、入ってくる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タイムスタンプが有効になる場合、着信接続要求（シンレイブ状態で接続を作成）を尊重します。

* 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セグメントのシーケンス番号は、接続の前の化身で見られる最後のシーケンス番号よりも大きい場合（データ転送の同じ方向に対して）、着信接続要求を尊重します（同期状態で接続を作成します）。

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

* それ以外の場合は、入ってくる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タイムスタンプを有効にしました）。それに応じて送信されます。また、タイムスタンプオプションも含まれます（つまり、サーバーが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.

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

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マイクロ秒ごとに約1回（つまり、約250,000回あたり250,000回）増分する必要があると述べています。その結果、250キロバイト/秒を超える250,000バイト以上のデータを転送する接続は、タイムウェイト状態に移動する接続で表示される最後のシーケンス番号がシーケンス番号よりも大きいシナリオにつながる可能性があります。同じ接続の新しい化身を作成することを目的とした、入ってくるシンセグメントの。これらのシナリオでは、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.

単調に増加するタイムスタンプは、提案されたアルゴリズムが以前の接続の化身の時間待機状態を減らすことができるようにしますが、アルゴリズムの実装は（それ自体）他の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.

最悪のシナリオでは、タイムウェイトの接続の新しい化身に対応する着信シンには、つながりの以前の化身で見られる最後のタイムスタンプよりも小さいタイムスタンプが含まれています。ヒューリスティックは失敗し、結果は現在の状況よりも悪くない。つまり、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.

一部のスタックでは、同じリモートエンドポイントを伴う接続全体で単調にタイムスタンプを増加させることにつながらないタイムスタンプ生成アルゴリズムを実装する場合があります。このようなアルゴリズムの例は、[RFC4987]および[Opperman]で説明されているアルゴリズムです。これにより、拡張TCP Syn Cookieの実装が可能です。

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 Cookie」は、単調に増加するようにタイムスタンプを生成するためのアルゴリズムと共存できることに注意する必要があります。アクティブオープンを実行するTCPインスタンスでは、単調に増加するタイムスタンプを生成できますが、パッシブオープンを実行するTCPインスタンスのタイムスタンプは[Opperman]に従って生成できます。

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]に記載されているように、このようなランダム化スキームは、このドキュメントで提案されているメカニズムが、時間待合状態の接続をリサイクルすることを防ぐ可能性があります。ただし、最悪のシナリオでこのセクションで前述したように、ヒューリスティックは失敗し、結果は現在の状況よりも悪くありません。

4. Interaction with Various ISN Generation Algorithms

4. さまざまなISN生成アルゴリズムとの相互作用

[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世代スキームは、予測可能な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の改善された取り扱いを破壊します。

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の存在下でも、時間と留保状態のリサイクルを可能にします。タイムウェイト状態の接続（データ転送の方向のため）。

5. Security Considerations

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

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

[TCP-Security]には、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).

このドキュメントは、テクニカルレポートの内容の一部に基づいています。「送信制御プロトコル（TCP）のセキュリティ評価」[CPNI-TCP]は、英国の保護センター（英国CPNI）を代表してFernando Gontによって書かれました。）。

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.

この文書の著者は、（アルファベット順の順序で）マーク・オールマン、フランシス・デュポン、ウェスリー・エディ、ラース・エガート、ジョン・ヘフナー、アルフレッド・ホーネス、クリスチャン・フイテマ、エリック・レスカルラ、ジョー・タッチ、アレクサンダー・ジマーマンに感謝します。このドキュメントの以前のバージョン。

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

さらに、著者は、IETF 73のTCPタイムスタンプに関する実り多い議論について、David Bormanに感謝したいと思います。

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

最後に、著者は、継続的な支援について国家インフラストラクチャの保護（英国CPNI）のために英国のセンターに感謝したいと思います。

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

Fernando GontのIETF会議への出席は、ISOCの「IETFへのフェローシップ」プログラムによってサポートされていました。

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., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122] Braden、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] Jacobson、V.、Braden、B。、およびD. Borman、「TCP拡張のための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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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、「伝送制御プロトコル（TCP）のセキュリティ評価」、2009、<http://www.cpni.gov.uk/docs/ tn-03-09-security-assessment-tcp.pdf>。

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

[Infocom-99] Faber、T.、Touch、J。、およびW. Yue、「TCPの時間待機状態と忙しいサーバーへの影響」、Proc。IEEE Infocom、1999、pp。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-Currentの拡張TCP Syncookies」、2006年9月、TCPMメーリングリストに投稿してください。/msg02251.html>。

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

[RFC1337] Braden、B。、「TCPにおける時間待ち暗殺の危険」、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] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、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-Security] Gont、F。、「送信制御プロトコル（TCP）のセキュリティ評価」、2011年1月の作業。

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

[TS-Generation] 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.

ホストが「Quiet Time Concept」に準拠していない場合、リモートホストの時間待合状態に同じ接続の以前の化身がある間、接続要求がリモートホストに送信される場合があります。このようなシナリオでは、以前のタイムスタンプの記憶を失った結果、結果として生じるタイムスタンプは単調に増加していない可能性があり、したがって提案されたアルゴリズムは、時間待合状態の接続の以前の化身をリサイクルできない可能性があります。このケースは、このドキュメントで提案されているアルゴリズムのない現在の状況に対応しています。

Author's Address

著者の連絡先

Fernando Gont UK Centre for the Protection of National Infrastructure

Fernando Gont UK Center for National Infrastructure

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