RFC1337 日本語訳
1337 TIME-WAIT Assassination Hazards in TCP. R. Braden. May 1992. (Format: TXT=22887 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden
Request for Comments: 1337 ISI
May 1992
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 1337 ISI1992年5月
TIME-WAIT Assassination Hazards in TCP
TCPの時間待ち暗殺危険
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified.
この注意は、いくつかのTCP接続には、理論的に可能な故障モードを説明して、可能な療法について議論します。 特に、1つの非常に簡単なフィックスが特定されます。
1. INTRODUCTION
1. 序論
Experiments to validate the recently-proposed TCP extensions [RFC- 1323] have led to the discovery of a new class of TCP failures, which have been dubbed the "TIME-WAIT Assassination hazards". This note describes these hazards, gives examples, and discusses possible prevention measures.
最近提案されたTCP拡張子[RFC1323]を有効にする実験は新しいクラスのTCPの故障の発見につながりました。(故障は「タイム誌-WAIT Assassination危険」と呼ばれました)。 この注意は、これらの危険について説明して、例を挙げて、可能な防止策について議論します。
The failures in question all result from old duplicate segments. In brief, the TCP mechanisms to protect against old duplicate segments are [RFC-793]:
問題の失敗はすべて、古い写しセグメントから生じます。 要するに、古い写しセグメントに対して保護するTCPメカニズムは[RFC-793]です:
(1) The 3-way handshake rejects old duplicate initial <SYN>
segments, avoiding the hazard of replaying a connection.
(1) 接続を再演する危険を避けて、3ウェイ握手は古い写し初期の<SYN>セグメントを拒絶します。
(2) Sequence numbers are used to reject old duplicate data and ACK
segments from the current incarnation of a given connection
(defined by a particular host and port pair). Sequence numbers
are also used to reject old duplicate <SYN,ACK> segments.
(2) 一連番号は、与えられた接続(特定のホストとポート組によって定義される)の現在の肉体化から古い重複データとACKセグメントを拒絶するのに使用されます。 また、一連番号は、古い写し<SYN、ACK>セグメントを拒絶するのに使用されます。
For very high-speed connections, Jacobson's PAWS ("Protect
Against Wrapped Sequences") mechanism [RFC-1323] effectively
extends the sequence numbers so wrap-around will not introduce a
hazard within the same incarnation.
非常に高速な接続のために、ジェーコブソンのPAWS(「包装された系列から守る」)メカニズム[RFC-1323]が事実上一連番号を広げているので、巻きつけて着るドレスは同じ肉体化の中で危険を導入しないでしょう。
(3) There are two mechanisms to avoid hazards due to old duplicate
segments from an earlier instance of the same connection; see
the Appendix to [RFC-1185] for details.
(3) 古い写しセグメントのため同じ接続の以前の例から危険を避けるために、2つのメカニズムがあります。 詳細に関して[RFC-1185]へのAppendixを見てください。
Braden [Page 1] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[1ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
For "short and slow" connections [RFC-1185], the clock-driven
ISN (initial sequence number) selection prevents the overlap of
the sequence spaces of the old and new incarnations [RFC-793].
(The algorithm used by Berkeley BSD TCP for stepping ISN
complicates the analysis slightly but does not change the
conclusions.)
「短く遅い」接続[RFC-1185]のために、時計駆動のISN(初期シーケンス番号)選択は古くて新しい肉体化[RFC-793]の系列空間のオーバラップを防ぎます。 (ISNを踏むのにバークレーBSD TCPによって使用されたアルゴリズムは、分析をわずかに複雑にしますが、結論を変えません。)
(4) TIME-WAIT state removes the hazard of old duplicates for "fast"
or "long" connections, in which clock-driven ISN selection is
unable to prevent overlap of the old and new sequence spaces.
The TIME-WAIT delay allows all old duplicate segments time
enough to die in the Internet before the connection is reopened.
(4) タイム誌-WAIT州は「速い」か「長い」接続に古い写しの危険を移します。(そこでは、時計駆動のISN選択が古くて新しい系列空間のオーバラップを防ぐことができません)。 タイム誌-WAIT遅れはすべての古い写しセグメント時間に接続が再開する前にインターネットで死ぬことができるくらい許容します。
(5) After a system crash, the Quiet Time at system startup allows
old duplicates to disappear before any connections are opened.
(5) システムクラッシュの後に、どんな接続も開かれる前にシステム起動におけるQuiet Timeは古い写しを見えなくならせます。
Our new observation is that (4) is unreliable: TIME-WAIT state can be
prematurely terminated ("assassinated") by an old duplicate data or
ACK segment from the current or an earlier incarnation of the same
connection. We refer to this as "TIME-WAIT Assassination" (TWA).
私たちの新しい観測は(4)が頼り無いということです: タイム誌-WAIT状態は、同じ接続の現在の肉体化か以前の肉体化からの早まって古い写しによって終えられた(「暗殺される」)データかACKセグメントであるかもしれません。 私たちは「時間待ち暗殺」(TWA)にこれについて言及します。
Figure 1 shows an example of TIME-WAIT assassination. Segments 1-5 are copied exactly from Figure 13 of RFC-793, showing a normal close handshake. Packets 5.1, 5.2, and 5.3 are an extension to this sequence, illustrating TWA. Here 5.1 is *any* old segment that is unacceptable to TCP A. It might be unacceptable because of its sequence number or because of an old PAWS timestamp. In either case, TCP A sends an ACK segment 5.2 for its current SND.NXT and RCV.NXT. Since it has no state for this connection, TCP B reflects this as RST segment 5.3, which assassinates the TIME-WAIT state at A!
図1はタイム誌-WAIT暗殺に関する例を示しています。 通常の厳密な握手を示して、セグメント1-5はちょうどRFC-793の図13からコピーされます。 TWAを例証して、パケット5.1、5.2、および5.3はこの系列への拡大です。 ここで、5.1は*どんなTCP A.Itに容認できない*古いセグメントも一連番号のため古いPAWSタイムスタンプので容認できないかもしれないということです。 どちらの場合ではも、TCP Aはその現在のSND.NXTとRCV.NXTのためにACKセグメント5.2を送ります。 それにはこの接続のための状態が全くないので、TCP BはRSTセグメント5.3としてこれを反映します!(それは、Aでタイム誌-WAIT状態を暗殺します)。
Braden [Page 2] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[2ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
TCP A TCP B
TCPはTCP Bです。
1. ESTABLISHED ESTABLISHED
1. 確立していた状態で、設立されます。
(Close)
2. FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
(閉鎖。)2 フィン待1ち--フィン、ACK><SEQ=100><ACK=300><CTL=>-->の厳密な待ち
3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
3. フィン待2ち<--<SEQ=300><ACK=101><CTL=ACK><--厳密な待ち
(Close)
4. TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
(閉鎖。)4 時間待ち<--<SEQ=300><ACK=101><CTL=フィン、ACK><--最後のACK
5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
5. 時間待ち--><SEQ=101><ACK=301><CTL=ACK>-->は閉じました。
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
5.1. TIME-WAIT <-- <SEQ=255><ACK=33> ... old duplicate
5.1. タイム誌-WAIT<--<の>の<のACK=33の>の…古いSEQ=255写し
5.2 TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> ????
5.2時間待ち--><SEQ=101><ACK=301><CTL=ACK>-->?
5.3 CLOSED <-- <SEQ=301><CTL=RST> <-- ????
(prematurely)
5.3 閉じている<(<SEQ=301><CTL=RST><)? (早まって)
Figure 1. TWA Example
図1。 TWAの例
Note that TWA is not at all an unlikely event if there are any duplicate segments that may be delayed in the network. Furthermore, TWA cannot be prevented by PAWS timestamps; the event may happen within the same tick of the timestamp clock. TWA is a consequence of TCP's half-open connection discovery mechanism (see pp 33-34 of [RFC-793]), which is designed to clean up after a system crash.
何かネットワークで遅れる写しセグメントがあればTWAがありそうもない出来事にないことに注意してください。 その上、PAWSタイムスタンプはTWAを防ぐことができません。 出来事はタイムスタンプ時計の同じカチカチする音の中で起こるかもしれません。 TWAはTCPの半開きな接続発見メカニズム([RFC-793]のpp33-34を見る)の結果です。(それは、システムクラッシュの後に掃除するように設計されています)。
2. The TWA Hazards
2. TWA危険
2.1 Introduction
2.1 序論
If the connection is immediately reopened after a TWA event, the
new incarnation will be exposed to old duplicate segments (except
for the initial <SYN> segment, which is handled by the 3-way
handshake). There are three possible hazards that result:
接続がTWA出来事の後にすぐに再開すると、新しい肉体化は古い写しセグメント(初期の<SYN>セグメントを除いた)に露出されるでしょう。セグメントは3ウェイ握手で扱われます。 結果として生じる3つの可能な危険があります:
H1. Old duplicate data may be accepted erroneously.
H1。 誤って古い重複データを受け入れるかもしれません。
H2. The new connection may be de-synchronized, with the two ends
in permanent disagreement on the state. Following the spec
of RFC-793, this desynchronization results in an infinite ACK
H2。 新しい接続は状態で反-永久的な不一致への2つの終わりと同時にするかもしれません。 この脱同期化は無限のACKをもたらして、RFC-793の仕様に続きます。
Braden [Page 3] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[3ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
loop. (It might be reasonable to change this aspect of RFC-
793 and kill the connection instead.)
輪にしてください。 (RFC793のこの局面を変えて、代わりに接続を殺すのは妥当であるかもしれません。)
This hazard results from acknowledging something that was not
sent. This may result from an old duplicate ACK or as a
side-effect of hazard H1.
この危険は送られなかった何か承認しているものから生じます。 これは古い写しACKか危険H1の副作用として結果として生じるかもしれません。
H3. The new connection may die.
H3。 新しい接続は死ぬかもしれません。
A duplicate segment (data or ACK) arriving in SYN-SENT state
may kill the new connection after it has apparently opened
successfully.
明らかに首尾よく開いた後に、SYN-SENT状態に到着する写しセグメント(データかACK)で、新しい接続は死ぬかもしれません。
Each of these hazards requires that the seqence space of the new
connection overlap to some extent with the sequence space of the
previous incarnation. As noted above, this is only possible for
"fast" or "long" connections. Since these hazards all require the
coincidence of an old duplicate falling into a particular range of
new sequence numbers, they are much less probable than TWA itself.
それぞれのこれらの危険は、新しい接続のseqenceスペースが前の肉体化の系列スペースにある程度重なるのを必要とします。 上で述べたように、「速い」か「長い」接続だけには、これは可能です。 これらの危険がすべて、特定の範囲の新しい一連番号になる古い写しの偶然の一致を必要とするので、それらはTWA自身よりあまりありえそうではありません。
TWA and the three hazards H1, H2, and H3 have been demonstrated on
a stock Sun OS 4.1.1 TCP running in an simulated environment that
massively duplicates segments. This environment is far more
hazardous than most real TCP's must cope with, and the conditions
were carefully tuned to create the necessary conditions for the
failures. However, these demonstrations are in effect an
existence proof for the hazards.
TWAと3はH1を危険にさらします、H2、そして、H3が、セグメントを膨大にコピーするシミュレート環境に立候補しながら、ストックSun OS4.1.1TCPでデモをしました。 この環境は最も現実的なTCPのものが対処しなければならないよりはるかに危険です、そして、状態は、失敗のための必要条件を作成するために慎重に調整されました。 しかしながら、事実上、これらのデモンストレーションは危険のための存在証拠です。
We now present example scenarios for each of these hazards. Each
scenario is assumed to follow immediately after a TWA event
terminated the previous incarnation of the same connection.
私たちは現在、それぞれのこれらの危険のために例のシナリオを提示します。 TWA出来事が同じ接続の前の肉体化を終えた直後各シナリオが続くと思われます。
2.2 HAZARD H1: Acceptance of erroneous old duplicate data.
2.2 H1を危険にさらしてください: 誤った古い重複データの承認。
Without the protection of the TIME-WAIT delay, it is possible for
erroneous old duplicate data from the earlier incarnation to be
accepted. Figure 2 shows precisely how this might happen.
タイム誌-WAIT遅れの保護がなければ、以前の肉体化からの誤った古い重複データを受け入れるのは可能です。 図2は、これが正確にどのように起こるかもしれないかを示します。
Braden [Page 4] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[4ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
TCP A TCP B
TCPはTCP Bです。
1. ESTABL. --> <SEQ=400><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
1. ESTABL。 --><SEQ=400><ACK=101><データは100><CTL=ACK>と等しいです-->ESTABL。
2. ESTABL. <-- <SEQ=101><ACK=500><CTL=ACK> <-- ESTABL.
2. ESTABL。 <-- <SEQ=101><ACK=500><CTL=ACK><--ESTABL。
3. (old dupl)...<SEQ=560><ACK=101><DATA=80><CTL=ACK> --> ESTABL.
3. (古いdupl)...<SEQ=560><ACK=101><データは80><CTL=ACK>と等しいです-->ESTABL。
4. ESTABL. <-- <SEQ=101><ACK=500><CTL=ACK> <-- ESTABL.
4. ESTABL。 <-- <SEQ=101><ACK=500><CTL=ACK><--ESTABL。
5. ESTABL. --> <SEQ=500><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
5. ESTABL。 --><SEQ=500><ACK=101><データは100><CTL=ACK>と等しいです-->ESTABL。
6. ... <SEQ=101><ACK=640><CTL=ACK> <-- ESTABL.
6. ... <SEQ=101><ACK=640><CTL=ACK><--ESTABL。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
7a. ESTABL. --> <SEQ=600><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
7a。 ESTABL。 --><SEQ=600><ACK=101><データは100><CTL=ACK>と等しいです-->ESTABL。
8a. ESTABL. <-- <SEQ=101><ACK=640><CTL=ACK> ...
8a。 ESTABL。 <-- <SEQ=101><ACK=640><CTL=ACK>…
9a. ESTABL. --> <SEQ=700><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
9a。 ESTABL。 --><SEQ=700><ACK=101><データは100><CTL=ACK>と等しいです-->ESTABL。
Figure 2: Accepting Erroneous Data
図2: 誤ったデータを受け入れます。
The connection has already been successfully reopened after the
assumed TWA event. Segment 1 is a normal data segment and segment
2 is the corresponding ACK segment. Old duplicate data segment 3
from the earlier incarnation happens to fall within the current
receive window, resulting in a duplicate ACK segment #4. The
erroneous data is queued and "lurks" in the TCP reassembly queue
until data segment 5 overlaps it. At that point, either 80 or 40
bytes of erroneous data is delivered to the user B; the choice
depends upon the particulars of the reassembly algorithm, which
may accept the first or the last duplicate data.
接続は想定されたTWA出来事の後に既に首尾よく再開しました。 セグメント1は正常なデータ・セグメントです、そして、セグメント2は対応するACKセグメントです。 以前の肉体化からの古い重複データセグメント3は、窓を受けて、写しACKセグメント#4をもたらしながら、電流の中でたまたま低下します。 データ・セグメント5がそれを重ね合わせるまで、誤ったデータは、TCP reassembly待ち行列で列に並ばせられて、「潜んでいます」。 その時、80バイトか40バイトの誤ったデータをユーザBに送ります。 選択は再アセンブリアルゴリズムの子細か最後の重複データによります。アルゴリズムは1番目を受け入れるかもしれません。
As a result, B sends segment 6, an ACK for sequence = 640, which
is 40 beyond any data sent by A. Assume for the present that this
ACK arrives at A *after* A has sent segment 7a, the next full data
segment. In that case, the ACK segment 8a acknowledges data that
has been sent, and the error goes undetected. Another possible
continuation after segment 6 leads to hazard H3, shown below.
その結果、Bは系列=640のためにセグメント6、ACKを送って、どれが向こうの何かデータがこのACKがA*に到着するプレゼントのためにA.Assumeで送った*Aが送った40であるかは7a、次の完全なデータ・セグメントを区分します。 その場合、ACKセグメント8aは送られたデータを承認します、そして、誤りは察知されずにいます。 セグメント6の後の別の可能な継続は以下で見せられた危険H3に通じます。
2.3 HAZARD H2: De-synchronized Connection
2.3 H2を危険にさらしてください: 反-連動している接続
This hazard may result either as a side effect of H1 or directly
from an old duplicate ACK that happens to be acceptable but
acknowledges something that has not been sent.
この危険はH1の副作用、または、直接たまたま許容できますが、送られない何かを承認する古い写しACKから結果として生じるかもしれません。
Braden [Page 5] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[5ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
Referring to Figure 2 above, suppose that the ACK generated by the
old duplicate data segment arrived before the next data segment
had been sent. The result is an infinite ACK loop, as shown by
the following alternate continuation of Figure 2.
図2を参照して、次のデータ・セグメントを送る前に上では、古い重複データセグメントで発生するACKが到着したと仮定してください。 結果は図2の以下の交互の継続で示されるように無限のACK輪です。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
7b. ESTABL. <-- <SEQ=101><ACK=640><CTL=ACK> ...
(ACK something not yet
sent => send ACK)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7b。 ESTABL。 <-- <SEQ=101><ACK=640><CTL=ACK>… (何かがまだ=>を送らなかったACKはACKを送ります)
8b. ESTABL. --> <SEQ=600><ACK101><CTL=ACK> --> ESTABL.
(Below window =>
send ACK)
8b。 ESTABL。 --><SEQ=600><ACK101><CTL=ACK>-->ESTABL。 (窓=>の下に、ACKを送ってください)
9b. ESTABL. <-- <SEQ=101><ACK=640><CTL=ACK> <-- ESTABL.
9b。 ESTABL。 <-- <SEQ=101><ACK=640><CTL=ACK><--ESTABL。
(etc.!)
(など!)
Figure 3: Infinite ACK loop
図3: 無限のACK輪
2.4 HAZARD H3: Connection Failure
2.4 H3を危険にさらしてください: 接続失敗
An old duplicate ACK segment may lead to an apparent refusal of
TCP A's next connection attempt, as illustrated in Figure 4. Here
<W=...> indicates the TCP window field SEG.WIND.*
古い写しACKセグメントはTCP Aの次の接続試みの見かけの拒否につながるかもしれません、図4で例証されるように。 ここで、<W=…>は、TCPの窓がSEG.WIND*をさばくのを示します。
TCP A TCP B
TCPはTCP Bです。
1. CLOSED LISTEN
1. 閉じられて、聴いてください。
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RCVD
2. SYNによって送られた(><SEQ=100><CTL=SYN>)>SYN-RCVD
3. ... <SEQ=400><ACK=101><CTL=SYN,ACK><W=800> <-- SYN-RCVD
3. ... <SEQ=400><ACK=101><CTL=SYN、ACK><W=800><--SYN-RCVD
4. SYN-SENT <-- <SEQ=300><ACK=123><CTL=ACK> ... (old duplicate)
4. SYNによって送られた<--<SEQ=300><ACK=123><CTL=ACK>… (古い写し)
5. SYN-SENT --> <SEQ=123><CTL=RST> --> LISTEN
5. SYNによって送られた(><SEQ=123><CTL=RST>)>は聴かれます。
6. ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK><W=900> ...
6. 確立した<--<SEQ=400><ACK=101><CTL=SYN、ACK><W=900>…
7. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> LISTEN
7. 確立した(><SEQ=101><ACK=401><CTL=ACK>)>は聴かれます。
8. CLOSED <-- <SEQ=401><CTL=RST> <-- LISTEN
8. 閉じている<(<SEQ=401><CTL=RST><)は聴かれます。
Figure 4: Connection Failure from Old Duplicate
図4: 古い写しからの接続失敗
Braden [Page 6] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[6ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
The key to the failure in Figure 4 is that the RST segment 5 is
acceptable to TCP B in SYN-RECEIVED state, because the sequence
space of the earlier connection that produced this old duplicate
overlaps the new connection space. Thus, <SEQ=123> in segment #5
falls within TCP B's receive window [101,900). In experiments,
this failure mode was very easy to demonstrate. (Kurt Matthys has
pointed out that this scenario is time-dependent: if TCP A should
timeout and retransmit the initial SYN after segment 5 arrives and
before segment 6, then the open will complete successfully.)
図4での失敗のキーによるRSTセグメント5がSYN-RECEIVED状態でTCP Bに許容できるということです、この古い写しを製作した以前の接続の系列スペースが新しい接続スペースを重ね合わせるので。 したがって、TCPビーズの中のセグメント#5つの滝の<SEQ=123>は窓[101,900)を受けます。実験では、この故障モードは非常に示しやすかったです。セグメント5が到着した後とセグメント6の前に初期のSYNを再送してください、戸外が完成するその時。そして、(カート・マシスは、このシナリオに時間依存していると指摘しました: AがTCPであるならそうするべきである、タイムアウト、首尾よい)。
3. Fixes for TWA Hazards
3. TWA危険のためのフィックス
We discuss three possible fixes to TCP to avoid these hazards.
私たちは、これらの危険を避けるために3つの可能なフィックスについてTCPと議論します。
(F1) Ignore RST segments in TIME-WAIT state.
(F1) タイム誌-WAIT状態でRSTセグメントを無視してください。
If the 2 minute MSL is enforced, this fix avoids all three
hazards.
2の微小なMSLが実施されるなら、このフィックスはすべての3つの危険を避けます。
This is the simplest fix. One could also argue that it is
formally the correct thing to do; since allowing time for old
duplicate segments to die is one of TIME-WAIT state's functions,
the state should not be truncated by a RST segment.
これは最も簡単なフィックスです。 また、1つが、それが正式にそうであると主張するかもしれない、する正しいこと。 古い写しセグメントが消え失せる時間を許容するのが、タイム誌-WAIT状態の機能の1つであるので、RSTセグメントで状態に先端を切らせるべきではありません。
(F2) Use PAWS to avoid the hazards.
(F2)は、危険を避けるのにPAWSを使用します。
Suppose that the TCP ignores RST segments in TIME-WAIT state,
but only long enough to guarantee that the timestamp clocks on
both ends have ticked. Then the PAWS mechanism [RFC-1323] will
prevent old duplicate data segments from interfering with the
new incarnation, eliminating hazard H1. For reasons explained
below, however, it may not eliminate all old duplicate ACK
segments, so hazards H2 and H3 will still exist.
TCPがタイム誌-WAIT状態にもかかわらず、長くだけ両端のタイムスタンプ時計がカチカチしたのを保証するのに十分でRSTセグメントを無視すると仮定してください。 そして、PAWSメカニズム[RFC-1323]は、危険H1を排除して、古い重複データセグメントが新しい肉体化を妨げるのを防ぐでしょう。 以下で説明された理由で、しかしながら、すべての古い写しACKセグメントを排除するかもしれないというわけではないので、それでも、危険のH2とH3は存在するでしょう。
In the language of the TCP Extensions RFC [RFC-1323]:
TCP Extensions RFC[RFC-1323]の言葉を借りて言えば:
When processing a RST bit in TIME-WAIT state:
処理するとき、RSTはタイム誌-WAIT状態で噛み付きました:
If (Snd.TS.OK is off) or (Time.in.TW.state() >= W)
then enter the CLOSED state, delete the TCB,
drop the RST segment, and return.
または、(Snd.TS.OKはオフです)、(Time.in.TW.state()>はWと等しいです) 次に、CLOSED状態に入れてください、そして、TCBを削除してください、そして、RSTセグメントを落としてください、そして、戻ってください。
else simply drop the RST segment and return.
ほか、単にRSTセグメントとリターンを落としてください。
Here "Time.in.TW.state()" is a function returning the elapsed
time since TIME-WAIT state was entered, and W is a constant that
is at least twice the longest possible period for timestamp
clocks, i.e., W = 2 secs [RFC-1323].
ここで、タイム誌-WAIT状態が入られたので、"Time.in.TW.state()"は経過時間を返す機能です、そして、Wは少なくともタイムスタンプ時計(すなわち、W=2秒[RFC-1323])のための可能な限り長い期間の2倍である定数です。
Braden [Page 7] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[7ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
This assumes that the timestamp clock at each end continues to
advance at a constant rate whether or not there are any open
connections. We do not have to consider what happens across a
system crash (e.g., the timestamp clock may jump randomly),
because of the assumed Quiet Time at system startup.
これは、各端のタイムスタンプ時計が、どんなオープンな接続もあるか否かに関係なく、一定の割合で進み続けていると仮定します。 私たちは、想定されたQuiet Timeのために、何がシステムクラッシュ(例えばタイムスタンプ時計は手当たりしだいにジャンプするかもしれない)の向こう側にシステム起動で起こるかを考える必要はありません。
Once this change is in place, the initial timestamps that occur
on the SYN and {SYN,ACK} segments reopening the connection will
be larger than any timestamp on a segment from earlier
incarnations. As a result, the PAWS mechanism operating in the
new connection incarnation will avoid the H1 hazard, ie.
acceptance of old duplicate data.
前からのセグメントに関する何より大きいタイムスタンプが肉体化であったなら、かつて、この変化は、接続を再開させるセグメントがそうする初期の適所にあってSYNに現れるタイムスタンプとSYN、ACKです。 その結果、新しい接続肉体化で動作するPAWSメカニズムはH1危険ie(古い重複データの承認)を避けるでしょう。
The effectiveness of fix (F2) in preventing acceptance of old
duplicate data segments, i.e., hazard H1, has been demonstrated
in the Sun OS TCP mentioned earlier. Unfortunately, these tests
revealed a somewhat surprising fact: old duplicate ACKs from
the earlier incarnation can still slip past PAWS, so that (F2)
will not prevent failures H2 or H3. What happens is that TIME-
WAIT state effectively regenerates the timestamp of an old
duplicate ACK. That is, when an old duplicate arrives in TIME-
WAIT state, an extended TCP will send out its own ACK with a
timestamp option containing its CURRENT timestamp clock value.
If this happens immediately before the TWA mechanism kills
TIME-WAIT state, the result will be a "new old duplicate"
segment with a current timestamp that may pass the PAWS test on
the reopened connection.
古い重複データセグメントの承認を防ぐことにおける、フィックス(F2)の有効性(すなわち、危険H1)は、より早く言及されたSun OS TCPに示されました。 残念ながら、これらのテストはいくらか驚異的な事実を明らかにしました: 以前の肉体化からの古い写しACKsはまだPAWSを知らぬ間に過ぎることができます、(F2)が失敗H2かH3を防がないように。 起こることは事実上、タイム誌WAIT州が古い写しACKに関するタイムスタンプを作り直すということです。 すなわち、古い写しがタイム誌WAIT状態に到着するとき、拡張TCPはタイムスタンプオプションがCURRENTタイムスタンプ時計価値を含んでいるそれ自身のACKを出すでしょう。 TWAメカニズムがタイム誌-WAIT状態を破壊する直前これが起こると、結果は再開している接続のPAWSテストに合格するかもしれない現在のタイムスタンプをもって「ニュー・オールド写し」セグメントになるでしょう。
Whether H2 and H3 are critical depends upon how often they
happen and what assumptions the applications make about TCP
semantics. In the case of the H3 hazard, merely trying the open
again is likely to succeed. Furthermore, many production TCPs
have (despite the advice of the researchers who developed TCP)
incorporated a "keep-alive" mechanism, which may kill
connections unnecessarily. The frequency of occurrence of H2
and H3 may well be much lower than keep-alive failures or
transient internet routing failures.
H2とH3が重要であるかどうかがどれくらいの頻度で起こるか、そして、アプリケーションがTCP意味論に関してどんな仮定をするかによります。 H3危険の場合では、再び単に戸外を試みるのは成功しそうです。 その上、多くの生産TCPsは「生きている生活費」メカニズムを組み込みました(TCPを開発した研究者のアドバイスにもかかわらず)。(それは、不必要に接続を殺すかもしれません)。 たぶん、H2とH3の発生の頻度は失敗か一時的なインターネットルーティング失敗を生かすよりたくさん下ろすことでしょう。
(F3) Use 64-bit Sequence Numbers
(F3)は64ビットの一連番号を使用します。
O'Malley and Peterson [RFC-1264] have suggested expansion of the
TCP sequence space to 64 bits as an alternative to PAWS for
avoiding the hazard of wrapped sequence numbers within the same
incarnation. It is worthwhile to inquire whether 64-bit
sequence numbers could be used to avoid the TWA hazards as well.
オマリーとピーターソン[RFC-1264]は同じ肉体化の中で包装された一連番号の危険を避けるためのPAWSに代わる手段としてTCP系列スペースの拡大を64ビットまで勧めました。 また、TWA危険を避けるのに64ビットの一連番号を使用できたかどうか問い合わせる価値があります。
Using 64 bit sequence numbers would not prevent TWA - the early
termination of TIME-WAIT state. However, it appears that a
64ビットの一連番号を使用するのはTWAを防がないでしょう--タイム誌-WAIT状態の期限前契約解除。 しかしながら、それはそのaに見えます。
Braden [Page 8] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[8ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
combination of 64-bit sequence numbers with an appropriate
modification of the TCP parameters could defeat all of the TWA
hazards H1, H2, and H3. The basis for this is explained in an
appendix to this memo. In summary, it could be arranged that
the same sequence space would be reused only after a very long
period of time, so every connection would be "slow" and "short".
TCPパラメタの適切な変更への64ビットの一連番号の組み合わせはTWA危険のH1、H2、およびH3のすべてを破るかもしれません。 この基礎は付録でこのメモに説明されます。 したがって、すべての接続が、概要では、そんなに同じ整っている系列スペースが時間の非常に長い期間の後にだけ再利用されるだろうということであるかもしれなく、「遅く」「短いでしょう」。
4. Conclusions
4. 結論
Of the three fixes described in the previous section, fix (F1), ignoring RST segments in TIME-WAIT state, seems like the best short- term solution. It is certainly the simplest. It would be very desirable to do an extended test of this change in a production environment, to ensure there is no unexpected bad effect of ignoring RSTs in TIME-WAIT state.
前項で説明された3つのフィックスでは、タイム誌-WAIT状態でRSTセグメントを無視して、フィックス(F1)は解決策という最も良い短い期間のように見えます。 確かに、それは最も簡単です。 実稼動環境でこの変化の拡張テストをするのは、タイム誌-WAIT状態でRSTsを無視するというどんな予期していなかった悪い効果もないのを保証するために非常に望ましいでしょう。
Fix (F2) is more complex and is at best a partial fix. (F3), using 64-bit sequence numbers, would be a significant change in the protocol, and its implications need to be thoroughly understood. (F3) may turn out to be a long-term fix for the hazards discussed in this note.
フィックス(F2)は、より複雑であり、せいぜい部分的なフィックスです。 (F3), プロトコルにおける著しい変化であるだろう、64ビットの一連番号を使用して、含意は、徹底的に理解される必要があります。 (F3) この注意で議論した危険のための長期固定であると判明するかもしれません。
APPENDIX: Using 64-bit Sequence Numbers
付録: 64ビットの一連番号を使用します。
This appendix provides a justification of our statement that 64-bit sequence numbers could prevent the TWA hazards.
この付録は64ビットの一連番号がTWA危険を防ぐかもしれないという私たちの声明の正当化を提供します。
The theoretical ISN calculation used by TCP is:
TCPによって使用された理論上のISN計算は以下の通りです。
ISN = (R*T) mod 2**n.
ISNは(R*T)モッズ2**nと等しいです。
where T is the real time in seconds (from an arbitrary origin, fixed when the system is started), R is a constant, currently 250 KBps, and n = 32 is the size of the sequence number field.
Tが秒(システムが始動されるとき修理された任意の起源からの)のリアルタイムであるところでは、Rは定数です、現在の250KBps、そして、n=32は一連番号分野のサイズです。
The limitations of current TCP are established by n, R, and the maximum segment lifetime MSL = 4 minutes. The shortest time Twrap to wrap the sequence space is:
現在のTCPの限界はn、R、および4MSL=分の最大のセグメント生涯までに設置されます。 系列スペースを包装する最も短い間Twrapは以下の通りです。
Twrap = (2**n)/r
Twrapは/rと等しいです(2**n)。
where r is the maximum transfer rate. To avoid old duplicate segments in the same connection, we require that Twrap > MSL (in practice, we need Twrap >> MSL).
rが最大の転送であるところでは、評価してください。 同じ接続における古い写しセグメントを避けるために、私たちはそのTwrap>MSLを必要とします(実際には、私たちはTwrap>>MSLを必要とします)。
Braden [Page 9] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[9ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
The clock-driven ISN numbers wrap in time TwrapISN:
時計でやる気満々のISN番号は時間内に、TwrapISNを包装します:
TwrapISN = (2**n)/R
TwrapISNは/Rと等しいです(2**n)。
For current TCP, TwrapISN = 4.55 hours.
4.55現在のTCP、TwrapISN=時間。
The cases for old duplicates from previous connections can be divided into four regions along two dimensions:
二次元に沿って前の接続からの古い写しのためのケースを4つの領域に分割できます:
* Slow vs. fast connections, corresponding to r < R or r >= R.
* r<Rかr>=Rに対応する、速い接続に対して遅くなってください。
* Short vs. long connections, corresponding to duration E <
TwrapISN or E >= TwrapISN.
* 長い接続に対して短くて、持続時間E<TwrapISNかE>に対応するのはTwrapISNと等しいです。
On short slow connections, the clock-driven ISN selection rejects old duplicates. For all other cases, the TIME-WAIT delay of 2*MSL is required so old duplicates can expire before they infect a new incarnation. This is discussed in detail in the Appendix to [RFC- 1185].
背の低い遅い接続のときに、時計駆動のISN選択は古い写しを拒絶します。 他のすべてのケースにおいて、2*MSLのタイム誌-WAIT遅れが、新しい肉体化を感染させる前に古い写しが期限が切れることができるように必要です。 Appendixで詳細に[RFC1185]とこれについて議論します。
With this background, we can consider the effect of increasing n to 64. We would like to increase both R and TwrapISN far enough that all connections will be short and slow, i.e., so that the clock- driven ISN selection will reject all old duplicates. Put another way, we want to every connection to have a unique chunk of the seqence space. For this purpose, we need R larger than the maximum foreseeable rate r, and TwrapISN greater than the longest foreseeable connection duration E.
このバックグラウンドで、私たちはnから64に増加するという効果を考えることができます。 すべての接続が背が低くて、遅くなるほど遠くにRとTwrapISNの両方を増加させたいと思います、すなわち、時計の駆動ISN選択がすべての古い写しを拒絶するように。 別の方法を置いてください、そして、私たちは、seqenceスペースのユニークな塊が欲しいとすべての接続と思います。 このために、私たちは最大の予見できるレートrより大きいR、および最も長い予見できる接続持続時間EよりすばらしいTwrapISNを必要とします。
In fact, this appears feasible with n = 64 bits. Suppose that we use R = 2**33 Bps; this is approximately 8 gigabytes per second, a reasonable upper limit on throughput of a single TCP connection. Then TwrapISN = 68 years, a reasonable upper limit on TCP connection duration. Note that this particular choice of R corresponds to incrementing the ISN by 2**32 every 0.5 seconds, as would happen with the Berkeley BSD implementation of TCP. Then the low-order 32 bits of a 64-bit ISN would always be exactly zero.
事実上、これは64n=ビットで可能に見えます。 私たちが2**33R=Bpsを使用すると仮定してください。 これは1秒あたりおよそ8つのギガバイト、単独のTCP接続のスループットに関する妥当な上限です。 そして、TwrapISNはTCP接続持続時間で68年、妥当な上限と等しいです。 Rのこの特定の選択が0.5秒毎の2**32でISNを増加すると対応することに注意してください、TCPのバークレーのBSD実現で起こるだろうというとき。 そして、いつも64ビットのISNの下位の32ビットはちょうどゼロでしょう。
REFERENCES
参照
[RFC-793] Postel, J., "Transmission Control Protocol", RFC-793,
USC/Information Sciences Institute, September 1981.
[RFC-793] ポステル、J.、「通信制御プロトコル」、RFC-793、科学が1981年9月に設けるUSC/情報。
[RFC-1185] Jacobson, V., Braden, R., and Zhang, L., "TCP
Extension for High-Speed Paths", RFC-1185, Lawrence Berkeley Labs,
USC/Information Sciences Institute, and Xerox Palo Alto Research
Center, October 1990.
[RFC-1185]ジェーコブソン、V.とブレーデン、R.とチャン、L.、「高速経路のためのTCP拡張子」RFC-1185、ローレンスバークレー研究室、科学が設けるUSC/情報、およびゼロックスパロアルト研究センター(1990年10月)。
Braden [Page 10] RFC 1337 TCP TIME-WAIT Hazards May 1992
ブレーデン[10ページ]RFC1337TCP時間待ちは1992年5月を危険にさらします。
[RFC-1263] O'Malley, S. and L. Peterson, "TCP Extensions
Considered Harmful", RFC-1263, University of Arizona, October
1991.
[RFC-1263] オマリーとS.とL.ピーターソン、「有害であると考えられたTCP拡張子」、RFC-1263、アリゾナ大学、1991年10月。
[RFC-1323] Jacobson, V., Braden, R. and D. Borman "TCP Extensions
for High Performance", RFC-1323, Lawrence Berkeley Labs,
USC/Information Sciences Institute, and Cray Research, May 1992.
[RFC-1323]ジェーコブソン、V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC-1323、ローレンス・バークレー研究室、科学が設けるUSC/情報、およびクレイリサーチ(1992年5月)
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address:
作者のアドレス:
Bob Braden University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデン南カリフォルニア情報Sciences Institute大学4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (213) 822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 (213) 822-1511 メールしてください: Braden@ISI.EDU
Braden [Page 11]
ブレーデン[11ページ]
一覧
スポンサーリンク
