Independent Submission W. Simpson
Request for Comments: 6013 DayDreamer
Category: Experimental January 2011
ISSN: 2070-1721
TCP Cookie Transactions (TCPCT)
Abstract
抽象
TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks.
TCPクッキー取引（TCPCTは）接続のスプーフィングを阻止し、リソースの枯渇を防ぐため、初期ハンドシェイク中レスポンダ（サーバー）状態を解消します。イニシエータ（クライアント）接続の間に必要な遅延を確保するための唯一の責任があります。クッキー交換は、サービス攻撃の増幅及び反射拒絶を阻害するために限られたデータを搬送することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc6013.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6013で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
RFCとして公表のためにそれをフォーマットしたり、英語以外の言語に翻訳することを除いて、このドキュメントは変更されないことがあり、それの派生作品が作成されないことがあります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Protocol Overview ...............................................4
2.1. Message Summary (Simplified) ...............................6
2.2. Compatibility and Transparency .............................7
2.3. Fully Loaded Cookies .......................................7
2.4. TCP Header Extension .......................................8
2.5. <SYN> Option Handling ......................................9
3. Protocol Details ................................................9
3.1. TCP Cookie Option .........................................10
3.2. TCP Cookie-Pair Standard Option ...........................10
3.3. TCP Cookie-less Option ....................................11
3.4. TCP Timestamps Extended Option ............................11
3.5. Cookie Generation .........................................13
4. Cookie Exchange ................................................16
4.1. Initiator <SYN> ...........................................16
4.2. Responder <SYN,ACK(SYN)> ..................................17
4.3. Initiator <ACK(SYN)> ......................................17
4.4. Responder <ACK> ...........................................18
4.5. Simultaneous Open .........................................18
5. Accelerated Close ..............................................19
5.1. Initiator Close ...........................................20
5.2. Responder Close ...........................................20
6. Accelerated Open ...............................................21
6.1. Initiator <SYN> Data ......................................21
6.2. Responder <SYN,ACK(SYN)> Data .............................22
6.3. Initiator <ACK(SYN)> Data .................................23
6.4. Responder <ACK> Data ......................................24
7. Advisory Reset .................................................24
8. Interactions with Other Options ................................24
8.1. TCP Selective Acknowledgment ..............................25
8.2. TCP Timestamps ............................................25
8.3. TCP Extensions for Transactions ...........................25
8.4. TCP MD5 Signature .........................................25
8.5. TCP Authentication ........................................25
9. History ........................................................26
10. Acknowledgments ...............................................27
11. IESG Considerations ...........................................27
12. Operational Considerations ....................................28
13. Security Considerations .......................................28
Appendix A. Example Headers .......................................30
A.1. Example <SYN> Options .....................................30
A.2. Example <ACK(SYN)> with Sack ..............................31
A.3. Example <ACK(SYN)> with 64-bit Timestamps .................32
Normative References ..............................................33
Informative References ............................................34
TCP Cookie Transactions (TCPCT) provide a cryptologically secure mechanism to guard against simple flooding attacks sent with bogus IP [RFC791] Sources or TCP [RFC793] Ports. The initial TCP <SYN> exchange is vulnerable to forged IP Addresses, predictable Ports, and discoverable Sequence Numbers [Morris1985] [Gont2009]. (See also [RFC2827], [RFC3704], and [RFC4953].)
TCPクッキー取引（TCPCT）偽のIP [RFC791]ソースまたはTCP [RFC793]ポートに送信され、単純なフラッディング攻撃から保護するために暗号学の安全なメカニズムを提供します。初期TCP <SYN>交換が偽造IPアドレス、予測可能なポート、および発見シーケンス番号[Morris1985] [Gont2009]に対して脆弱です。 （また、[RFC2827]、[RFC3704]及び[RFC4953]を参照）。
During connection establishment, the cookie (nonce) exchange negotiates elimination of Responder (server) state. These cookies are later used to inhibit premature closing of connections, and reduce retention of state after the connection has terminated.
接続の確立時には、クッキー（ナンス）交換は、レスポンダ（サーバー）状態の解消を交渉します。これらのクッキーは、後で接続の早期閉鎖を阻害し、接続が終了した後の状態の保持を減らすために使用されています。
The cookie pair is much too large to fit with the other recommended options in the maximal 60 byte TCP header (40 bytes of option space). A successful option exchange signals availability of the TCP header extension, adding space for additional options.
クッキーのペアは、最大60バイトのTCPヘッダ内の他の推奨オプション（オプション空間の40バイト）と合わせてあまりにも大きいです。成功したオプションTCPヘッダ拡張の交換信号の可用性、追加オプションのためのスペースを追加します。
Also, implementations may optionally exchange limited amounts of transaction data during the initial cookie exchange, reducing network latency and host task context switching.
また、実装は必要に応じてネットワークの待ち時間とホストタスクコンテキストスイッチングを低減する、初期のクッキー交換中トランザクションで限定された量のデータを交換することができます。
Finally, implementations may optionally rapidly recycle prior connections. For otherwise stateless applications, this transparently facilitates persistent connections and pipelining of requests over each connection.
最後に、実装は、必要に応じて迅速に前の接続を再利用することができます。そうでない場合はステートレスなアプリケーションでは、これは透過的に持続的な接続と各接続を介して要求のパイプライン化を容易にします。
Many of these ideas have been previously proposed in one form or another (see History and Acknowledgments sections). This specification integrates these improvements into a coherent whole. Further motivation and rationale were detailed in [MSV2009].
これらのアイデアの多くは、以前に（歴史と謝辞のセクションを参照してください）1つの何らかの形で提案されています。この仕様は、コヒーレント全体にこれらの改善を統合します。さらに動機と理論的根拠は、[MSV2009]に詳述しました。
The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC2119].
キーワード "MAY"、「MUST、 "NOT MUST"、 "任意"、 "推奨"、 "必須"、 "SHOULD"、および "the" は本書では[RFC2119]で説明されるように解釈されるべきではありません。
byte An 8-bit quantity; also known as "octet" in standardese.
8ビット量バイト。またstandardeseで「オクテット」として知られています。
The TCPCT extensions consist of several simple phases:
TCPCTエクステンションには、いくつかの簡単な段階で構成されています。
1. Each party passes a "cookie" to the other. Due to limited space, only the most basic options are included.
1.各当事者は、他に「クッキー」を渡します。限られた空間に、唯一の最も基本的なオプションが含まれています。
The Cookie option also indicates that optional <SYN> data is acceptable. This data MAY be ignored by either party.
クッキーオプションは、オプションの<SYN>データが許容可能であることを示しています。このデータは、いずれかの当事者によって無視されるかもしれません。
A Responder that understands the Cookie option remains stateless.
クッキーのオプションを理解しResponderはステートレスのまま。
2. During the remainder of the standard TCP three-way handshake, the Timestamps and Cookie-Pair options guard the exchange.
2.標準のTCP 3ウェイハンドシェイクの残りの期間中、タイムスタンプやクッキーペアのオプションは、交換を守ります。
Other options present in the original <SYN> that were successfully returned in the <SYN,ACK(SYN)> MUST be included with the <ACK(SYN)>. Additional options MAY also be included as desired.
正常<SYN、ACK（SYN）>に戻したその<SYN>原に存在する他のオプションは、<ACK（SYN）>に含まれなければなりません。必要に応じて追加のオプションも含まれるかもしれません。
As there is no Responder state, it has no record of acknowledging previous data. Any optional <SYN> data MUST be retransmitted.
何レスポンダ状態が存在しないとして、それは以前のデータを認めるのレコードを持っていません。任意のオプションの<SYN>データを再送しなければなりません。
Upon verification of the Timestamps and Cookie-Pair, the Responder creates its Transport Control Block (TCB) [RFC793].
タイムスタンプとクッキーペアの検証の際に、レスポンダは、そのトランスポート制御ブロック（TCB）[RFC793]を作成します。
Note that the Responder returns the Cookie-Pair with its initial data, but subsequent data segments need only the Timestamps.
レスポンダは、その初期データとクッキーペアを返し、それ以降のデータセグメントのみタイムスタンプが必要であることに注意してください。
3. During close (or reset) of the TCP connection, the Timestamps and Cookie-Pair options guard the exchange.
3. TCPコネクションのクローズ（またはリセット）の際、タイムスタンプやクッキーペアのオプションは、交換を守ります。
Upon verification of the Timestamps and Cookie-Pair, the Responder removes its TCB.
タイムスタンプとクッキーペアの検証の際に、ResponderはそのTCBを削除します。
The sequence of messages is summarized in the diagram below.
メッセージのシーケンスは、以下の図に要約されています。
Initiator Responder
========= =========
<SYN> ->
base options
Timestamps
Cookie
[request data]
<- <SYN,ACK(SYN)>
base options
Timestamps
Cookie
[response data]
(stateless)
<ACK(SYN)> -> full options Timestamps Cookie-Pair [Sack(response)] data <- <ACK> full options Timestamps Cookie-Pair data (TCB state created) <- <ACK> Timestamps data
<ACK（SYN）> - >フルオプションのタイムスタンプクッキーペア[サック（応答）]データ< - <ACK>フルオプションのタイムスタンプクッキー対データ（TCB状態作成）< - <ACK>タイムスタンプデータ
<- <FIN,ACK> Timestamps Cookie-Pair <FIN,ACK(FIN)> -> Timestamps Cookie-Pair <- <ACK(FIN)> Timestamps Cookie-Pair (TCB state removed) TIME-WAIT
< - <FIN、ACK>タイムスタンプクッキーペア<FIN、ACK（FIN）> - >タイムスタンプクッキーペア< - <ACK（FIN）>タイムスタンプクッキーペア（TCB状態除去）TIME-WAIT
It is usually better that data arrive slowly, than not at all.
データが全くないよりも、ゆっくりと到着することは通常より良いです。
Many/most unmanaged middleboxes [RFC3234] (such as stateless firewalls, load balancers, intrusion detection systems, or network address translators [RFC3022]) cannot carry transport traffic other than TCP and UDP.
多くの/ほとんどの管理対象外のミドルボックス[RFC3234]（ステートレスファイアウォール、ロードバランサ、侵入検知システム、またはネットワークアドレス変換器としては、[RFC3022]）は、TCPおよびUDP以外のトランスポートのトラフィックを運ぶことができません。
Every TCP implementation MUST ignore without error any TCP option it does not implement ([RFC1122] section 4.2.2.5). In a study of the effects of middleboxes on transport protocols [MAF2004], the vast majority of modern TCP stacks correctly handle unknown TCP options. But it is still prudent to follow the [RFC793] "general principle of robustness: be conservative in what you do, be liberal in what you accept from others."
すべてのTCP実装は、エラーなしで、それは（[RFC1122]セクション4.2.2.5）を実装していない任意のTCPオプションを無視しなければなりません。トランスポートプロトコル[MAF2004]上のミドルボックスの効果の研究では、近代的なTCPスタックの大半は正しく、未知のTCPオプションを扱います。しかし、[RFC793]従うことがまだ賢明である「堅牢性の一般的な原則を：あなたは何をすべきかで保守的である、あなたが他の人から受け入れ何でリベラルこと」
Therefore, for each of the extensions defined here, an extension option will be sent in a <SYN,ACK(SYN)> segment only after the corresponding option was received in the original <SYN> segment.
したがって、ここで定義された拡張機能のそれぞれについて、拡張オプションは、対応するオプションは、元の<SYN>セグメントで受信された後にのみ<SYN、ACK（SYN）>セグメントで送信されるであろう。
Furthermore, TCP options will be sent on later segments only after an exchange of options has indicated that both parties understand the extension (see [RFC1323] [rfc1323bis] and its antecedents).
また、TCPオプションは、オプションの交換は（[RFC1323] [rfc1323bis]とその先行者を参照）双方が拡張を理解することが示された後にのみ、後セグメント上で送信されます。
Unfortunately, not all middleware adheres to these long-standing requirements. Instead, unknown <SYN> options are copied to the <SYN,ACK(SYN)>. This is indistinguishable from a Monkey in the Middle (MITM) reflection attack.
残念ながら、すべてのミドルウェアは、これらの長年の要件に準拠しています。代わりに、未知の<SYN>オプションは、<SYN、ACK（SYN）>にコピーされます。これはミドル（MITM）攻撃反射で猿と区別がつきません。
One Kind to aid them all, One Kind to find them,
One Kind to hold them all and in the header bind them.
The cookie exchange provides a singular opportunity to extend TCP with backward compatibility. Semantics for the option have been "overloaded" with a baker's dozen of capabilities and facilities.
クッキー交換は、下位互換性でTCPを拡張するための特異な機会を提供します。オプションのセマンティクスは、機能と施設のパンダースで「オーバーロードされた」されています。
A. First and foremost, the cookie exchange improves operational security for vulnerable servers against flooding attacks. The cookie exchange indicates that the Responder (server) will discard its initial state. All other semantics are subordinate.
A.まず第一に、クッキー交換はフラッディング攻撃に対して脆弱なサーバの運用、セキュリティが向上します。クッキー交換はレスポンダ（サーバー）がその初期状態を破棄することを示します。他のすべてのセマンティクスは従属しています。
B. Together with Sequence and Timestamp values, Cookie values protect against insertion and reflection attacks.
一緒にシーケンスおよびタイムスタンプ値を有するB.、クッキー値が挿入反射攻撃から保護します。
C. Cookie values allow applications to detect replay attacks.
C. Cookieの値には、アプリケーションがリプレイ攻撃を検出することを可能にします。
D. Cookie values MAY be used as an index or nonce for application security protocols. This facility is beyond the scope of this specification.
D. Cookieの値には、アプリケーションのセキュリティプロトコルのための指標やナンスとして使用することができます。この機能は、この仕様の範囲を超えています。
E. The <SYN> and <SYN,ACK(SYN)> MAY carry application data. This feature is entirely optional, and data is not guaranteed to pass successfully through middleware. Nor are the parties guaranteed to process this data without changes to the Application Program Interface (API). Such changes are beyond the scope of this specification.
E.ザ<SYN>及び<SYN、ACK（SYN）>は、アプリケーションデータを搬送することができます。この機能は完全に任意であり、データはミドルウェア正常に通過することが保証されていません。 NOR当事者は、アプリケーション・プログラム・インターフェース（API）を変更せずにこのデータを処理することが保証されています。このような変化は、この仕様の範囲を超えています。
F. The size of the cookies precludes most other options in the standard TCP header space. The cookie exchange negotiates TCP header extension.
F.は、クッキーの大きさは、標準的なTCPヘッダ空間で他のほとんどのオプションを排除します。クッキー交換は、TCPヘッダ拡張をネゴシエートします。
G. The cookie exchange and resulting TCP header extension permit negotiation of larger 64-bit (or 128-bit) Timestamps for paths with large bandwidth-delay products.
G.クッキー交換および大きな帯域幅遅延製品とパスのより大きい64ビット（128ビット）のタイムスタンプのTCPヘッダの拡張許可ネゴシエーションを結果として生じます。
H. TCP header extension frees some space for additional options.
H. TCPヘッダ拡張は、追加オプションのためのいくつかの領域を解放します。
I. Previously SYN-only options can be updated.
I.は、以前はSYN-オプションのみを更新することができます。
J. The cookie exchange indicates agreement to use accelerated close.
J.クッキー交換が促進近いを使用する契約を示しています。
K. The cookie exchange indicates agreement that only the Initiator (client) handles TIME-WAIT state.
K.クッキー交換は唯一のイニシエータ（クライアント）はTIME-WAIT状態を取り扱う契約を示しています。
L. The Timestamps and Cookie-Pair combination inhibits third parties from disrupting communications with <FIN> and <RST>.
L.ザタイムスタンプとクッキーペアの組み合わせは<FIN>と<RST>との通信を中断する第三者を阻害します。
M. The Timestamps and Cookie-Pair combination facilitates rapid reuse of the TCP Source Port with a common destination.
M.ザ・タイムスタンプとクッキーペアの組み合わせは、共通の宛先とTCP送信元ポートの迅速な再利用を容易にします。
Once the Cookie option has been successfully exchanged, TCP header extension is permitted. The Timestamps extended option (defined below) indicates the presence of the header extension.
クッキーオプションが正常に交換された後は、TCPヘッダの拡張が許可されています。タイムスタンプ拡張オプション（以下に定義）はヘッダ拡張の存在を示します。
Validation of known timestamp values protects against data corruption by misbehaving middleboxes.
知られているタイムスタンプ値の検証は、ミドルボックスを不正な動作により、データの破損を防ぎます。
As the Responder retains no TCB state after the initial TCP <SYN> exchange, all options present in the original <SYN> MUST be repeated.
Responderが初期TCP <SYN>交換後何TCBの状態を保持しないので、オリジナルの<SYN>に存在するすべてのオプションを繰り返さなければなりません。
For example, an option defined in the [RFC793] original specification -- Maximum Segment Size (MSS) -- previously appeared only in a <SYN> bearing segment (including <SYN,ACK(SYN)>). If present, MSS will be repeated in the Initiator <ACK(SYN)>, together with any additional options.
例えば、[RFC793]元の仕様で定義されたオプション - 最大セグメントサイズ（MSS）は、 - 以前にのみ（<SYN、ACK（SYN）>を含む）<SYN>軸受セグメントに登場しました。存在する場合、MSSは、一緒になって、任意の追加オプションで、イニシエータ<ACK（SYN）>に繰り返されます。
Generally, the Initiator MAY propose SYN-only options -- such as MSS -- anytime both Timestamps and Cookie-Pair options are present. These options are treated the same as with an original <SYN>. The Responder acknowledges using a subsequent <ACK> segment containing both Timestamps and Cookie-Pair options (similar to <SYN,ACK(SYN)> processing).
このようMSSとして - - いつでもタイムスタンプとクッキーペアの両方のオプションが存在している一般的には、イニシエータは、SYN-のみのオプションを提案することができます。これらのオプションは、元の<SYN>と同様に扱われます。レスポンダは、タイムスタンプと（<SYN、ACK（SYN）>処理と同様）クッキー対の両方のオプションを含む、後続の<ACK>セグメントを使用して認めています。
This facility allows previously SYN-only options to be updated from time to time. They take effect upon receipt.
この機能は、以前SYN-のみのオプションは、随時更新されることを可能にします。彼らは、受信時に有効になります。
However, <ACK> segments without data will not be delivered reliably. Any otherwise SYN-only options sent without data MUST be retransmitted with successive segments until sent with data (or <FIN>), and an <ACK> is received.
ただし、データのない<ACK>セグメントが確実に配信されません。データなしで送信され、さもなければSYN-唯一のオプションは（または<FIN>）データと共に送信されるまで連続セグメントと再送信されなければならない、と<ACK>が受信されます。
Another solution [RFC5452] describes use of an unpredictable Source Port. That is RECOMMENDED by this specification. See [RFC6056] for further information.
別の解決策[RFC5452]は予測不可能なソースポートの使用を記載しています。それは、この仕様で推奨されています。詳細については、[RFC6056]を参照してください。
An earlier solution [RFC1948] describes an unpredictable Initial Sequence Number (ISN). That is REQUIRED by this specification.
以前溶液[RFC1948]は予測不可能な初期シーケンス番号（ISN）を記述する。それは、この仕様によって必要とされます。
Support for the (32-bit) TCP Timestamps Option [RFC1323] is REQUIRED. A TSoffset SHOULD be generated per connection [GO2010]. The Don't Fragment (DF) bit MUST be set in the IP (v4) header.
（32ビット）TCPタイムスタンプオプション[RFC1323]のサポートが必要です。 TSoffset接続【GO2010】当たり生成されるべきです。 Do not Fragment（DF）ビットは、IP（V4）ヘッダに設定されなければなりません。
The TCP User Timeout Option [RFC5482] is RECOMMENDED.
TCPユーザタイムアウトオプション[RFC5482]は推奨されます。
Only one instance is permitted of any of the Cookie, Cookie-less, or Cookie-Pair option(s). Segments with duplicative or mutually exclusive options MUST be silently discarded.
唯一つのインスタンスは、クッキー、クッキーレス、またはクッキーペアオプション（複数可）の任意の許容されます。重複や相互に排他的なオプションを持つセグメントは黙って捨てなければなりません。
For examples, see Appendix A.
例については、付録Aを参照してください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 253 (experimental).
種類1バイト：定数253（実験）。
Length 1 byte: range 10 to 18 (bytes); limited by remaining space in the options field. The number MUST be even; the cookie is a multiple of 16 bits.
長さ1バイト：範囲10〜18（バイト）。オプションフィールドにスペースを残りによって制限されます。数は偶数でなければなりません。クッキーは、16ビットの倍数です。
Cookie 8 to 16 bytes (Length - 2): an unpredictable value.
クッキー8〜16バイト（長さ - 2）：予測できない値。
Options with invalid Length values MUST be ignored. The minimum Cookie size is 64 bits. If there is not sufficient space for a 64-bit cookie, this option MUST NOT be used.
無効な長さの値を持つオプションを無視しなければなりません。最小クッキーサイズは64ビットです。 64ビットのCookieの十分なスペースがない場合、このオプションは使用してはいけません。
The Responder Cookie MUST be the same size as the Initiator Cookie. The cookie pair is a multiple of 32 bits.
レスポンダクッキーは、イニシエータクッキーと同じサイズでなければなりません。クッキーペアは32ビットの倍数です。
Although the diagram shows a cookie aligned on 32-bit boundaries, that is not required.
図は、32ビット境界で整列クッキーを示しているが、それは必須ではありません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 253 (experimental).
種類1バイト：定数253（実験）。
Length 1 byte: range 18 to 34 (bytes). The number MUST be even; the cookie pair is a multiple of 32 bits.
長さ1バイト：範囲18〜34（バイト）。数は偶数でなければなりません。クッキーペアは32ビットの倍数です。
Initiator-Cookie 8 to 16 bytes, from the original <SYN>.
<SYN>元からイニシエータクッキー8〜16バイト。
Responder-Cookie 8 to 16 bytes, from the <SYN,ACK(SYN)>.
レスポンダクッキー<SYN、ACK（SYN）>から8〜16バイト。
The Cookie-Pair standard option only appears after the Timestamps extended option (below).
クッキーペア標準オプションはタイムスタンプの拡張オプション（下記）の後に表示されます。
Options with invalid Length values MUST be ignored. As the minimum Initiator-Cookie size is 64 bits, the minimum cookie pair is 128 bits (64 bits followed by 64 bits), while the maximum is 256 bits (128 bits followed by 128 bits).
無効な長さの値を持つオプションを無視しなければなりません。最小イニシエータクッキーのサイズは64ビットであり、最大は256ビット（128ビットが続く128ビット）であるが、最小クッキー対は、128ビット（64ビットに続く64ビット）です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 253 (experimental).
種類1バイト：定数253（実験）。
Length 1 byte: constant 2 (bytes). This distinguishes the option from other Cookie options.
長さ1バイト：定数2（バイト）。これは、他のクッキーのオプションからオプションを区別します。
Although no cookie is attached, this indicates that other features of this specification are available, including TCP header extension, Accelerated Close, Accelerated Open, and Advisory Reset. This is intended for use with TCP authentication options, beyond the scope of this specification.
クッキーが装着されていないが、これは本明細書の他の特徴は、TCPヘッダの拡張を含む、利用可能であることを示し、クローズ加速、オープン、および諮問リセットを加速させました。これは、この仕様の範囲を超えて、TCP認証オプションで使用するためのものです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | Extend | R | S |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ TS Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TS Echo Reply ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 254 (experimental).
種類1バイト：定数254（実験）。
Length 1 byte: constant 4 (bytes).
長さ1バイト：定数4（バイト）。
Extend 1 byte: range 9 to 255; the data offset (in 32-bit words) following the standard TCP header. Note this value MUST include the timestamp pair indicated by (S)ize.
255までの範囲9;：1つのバイトを拡張データは、標準のTCPヘッダに続く（32ビットワードに）オフセット。 IZEこの値が（S）で示されるタイムスタンプペアを含む必要があります。
(R)eserved 5 bits: default zero. Reserved for future use.
（5ビット予約：デフォルトのゼロを将来の使用のために予約されています。
(S)ize 3 bits:
（サイズ3ビット。
Other values are beyond the scope of this specification.
他の値は、この仕様の範囲を超えています。
TS Value 4, 8, or 16 bytes. The current value of the timestamp for the sender.
TS値4,8、または16バイト。送信者のためのタイムスタンプの現在の値。
TS Echo Reply 4, 8, or 16 bytes. A copy of the most recently received TS Value.
TSエコー応答4,8、または16バイト。最も最近受信したTS値のコピー。
The full timestamp pair follows the TCP header (indicated by +=+ delimiters) and maintains 32-bit alignment.
フルタイムスタンプペアは、（+ = +区切り文字によって示される）TCPヘッダに続く32ビットの整列を維持します。
This TCP header extension is ignored for sequence number computations. The Sequence Number of the first byte of segment data will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>.
このTCPヘッダ拡張は、シーケンス番号計算では無視されます。セグメントデータの最初のバイトのシーケンス番号は、<SYN>の初期シーケンス番号（ISN）プラスワン（1）であろう。
Every TCPCT implementation MUST recognize a Timestamps extended option. The larger 64-bit (or 128-bit) timestamps only appear in an extended option.
すべてのTCPCTの実装では、タイムスタンプ、拡張オプションを認識しなければなりません。より大きな64ビット（128ビット）のみ拡張オプションに表示されタイムスタンプ。
Segments with invalid Extend values MUST be silently discarded.
無効とセグメントは、値が静かに捨てなければなりません拡張します。
Only one instance is permitted of either the (32-bit) Timestamps standard option or this Timestamps extended option. Segments with duplicative or mutually exclusive options MUST be silently discarded.
唯一のインスタンスは（32ビット）のタイムスタンプ標準オプションまたはこのタイムスタンプ拡張オプションのいずれかの許容されます。重複や相互に排他的なオプションを持つセグメントは黙って捨てなければなりません。
Implementation Notes:
実装上の注意：
Serendipitous alignment allows simple loads and stores, instead of slower byte by byte iterations.
偶然のアライメントではなく、バイトの繰り返しによって遅くバイトの、シンプルなロードとストアができます。
When the TCP header is aligned on a 32-bit boundary and this is the only option, the timestamps in the extended header SHOULD be aligned on a 64-bit boundary. For both 32-bit and 64-bit timestamps, any data following the extended header will be aligned on a 64-bit boundary.
TCPヘッダは、32ビット境界で整列され、これが唯一のオプションである場合、拡張ヘッダ内のタイムスタンプは、64ビット境界で整列されるべきです。 32ビットおよび64ビットのタイムスタンプのために、拡張ヘッダに続く任意のデータは、64ビット境界で整列されます。
However, the 128-bit timestamps are not 128-bit aligned.
しかし、128ビットのタイムスタンプは、128ビットの整列されていません。
The technique by which a party generates a cookie is implementation dependent. The method chosen must satisfy some basic requirements:
当事者がクッキーを生成する技術は実装依存です。選択した方法は、いくつかの基本的な要件を満たしている必要があります。
1. The cookie MUST depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and TCP port, and then using it to swamp the victim with requests from randomly chosen IP addresses or ports.
1.クッキーは、特定の政党に依存しなければなりません。これは、実際のIPアドレスとTCPポートを使用してクッキーを取得した後、ランダムに選ばれたIPアドレスやポートからのリクエストで被害者を圧倒するためにそれを使用してから、攻撃者を防ぐことができます。
2. It MUST NOT be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie.
発行体以外の者は、そのエンティティによって受け入れられるクッキーを生成するため2.それは可能にすることはできません。これは、発行体がクッキーの生成とその後の検証でローカル秘密情報を使用することを意味します。任意の特定のCookieからこの秘密情報を推定することが可能であってはなりません。
3. The cookie generation and verification methods MUST be fast to thwart attacks intended to sabotage CPU resources.
3.クッキーの生成と検証方法は、CPUリソースを妨害することを意図した攻撃を阻止するために高速でなければなりません。
A recommended technique is to use a cryptographic hashing function.
推奨される技術は、暗号ハッシュ関数を使用することです。
An incoming cookie can be verified at any time by regenerating it locally from values contained in the incoming datagram and the local secret random value.
入ってくるクッキーは、着信データグラムとローカル秘密のランダムな値に含まれている値からローカルで再生することにより、いつでも確認することができます。
The Initiator secret value that affects its cookie SHOULD change for each new exchange, and is thereafter internally cached per TCB. This provides improved synchronization and protection against replay attacks.
そのクッキーに影響イニシエータ秘密の値は、それぞれの新しい交換のために変更する必要があり、その後、内部TCBごとにキャッシュされます。これは、リプレイ攻撃に対する改良された同期と保護を提供します。
An alternative is to cache the cookie instead of the secret value. Incoming cookies can be compared directly without the computational cost of regeneration.
代替は、秘密の値の代わりにクッキーをキャッシュすることです。着信クッキーは、再生の計算コストなしで直接比較することができます。
It is RECOMMENDED that the cookie be calculated over the secret value, the IP Source and Destination addresses, the TCP Source and Destination ports, and any (optional) Initiator <SYN> segment data.
クッキーが秘密の値、IP送信元アドレスと宛先アドレス、TCP送信元ポートと宛先ポート、および任意の（オプション）イニシエータ<SYN>セグメントデータ上で計算することが推奨されます。
Implementation Notes:
実装上の注意：
Although the recommendation includes the TCP Source Port, this is very implementation specific. For example, it might not be included when the value is constant or unknown.
勧告は、TCP送信元ポートが含まれていますが、これは非常に実装固有のものです。値が定数か不明な場合例えば、それは含まれていない可能性があります。
Likewise, segment data might not be included directly. For example, a pointer to the data could be included instead, with care taken to ensure the pointer changes anytime the data changes.
同様に、セグメントデータが直接含まれていない可能性があります。例えば、データへのポインタはポインタの変更にいつでもデータの変更を確実にするために注意しながら、代わりに含めることができます。
However, it is important that the implementation protect mutually suspicious users of the same system from generating the same cookie.
しかし、実装が同じCookieを生成するから、同じシステムの相互不審なユーザーを保護することが重要です。
The Responder secret value that affects its cookies remains the same for many different Initiators. However, this secret SHOULD be changed periodically to limit the time for use of its cookies (typically each 600 seconds).
そのクッキーに影響レスポンダ秘密の値は、多くの異なるイニシエータの同じまま。しかし、この秘密は、そのクッキー（通常は各600秒）の使用のための時間を制限するために、定期的に変更する必要があります。
The Responder-Cookie calculation MUST include its own TCP Sequence and Acknowledgment Numbers (after updating values), its own TCP Timestamps value, and the Initiator-Cookie value. This provides improved synchronization and protection against replay attacks.
レスポンダクッキー計算は、独自のTCPシーケンスおよび確認応答番号（値を更新した後）、それ自身のTCPタイムスタンプ値、及びイニシエータクッキー値を含まなければなりません。これは、リプレイ攻撃に対する改良された同期と保護を提供します。
It is RECOMMENDED that the cookie be calculated over the secret value, the IP Source and Destination addresses, its own TCP Destination Port (that is, the incoming Source Port), and the required values (above), followed by the secret value again.
クッキーが再び秘密値が続く秘密値、IP送信元アドレスと宛先アドレス、独自のTCP宛先ポート（つまり、入ってくる送信元ポートである）、および必要な値（上記）、上で計算することが推奨されます。
The cookie is not cached per Initiator to avoid saving state during the initial TCP <SYN> exchange. On receipt of a TCP <ACK(SYN)>, the Responder regenerates its cookie for validation.
クッキーは、初期TCP <SYN>交換時の状態を保存避けるために、イニシエータごとにキャッシュされていません。 TCP <ACK（SYN）>を受信すると、レスポンダは、検証のためにそのクッキーを再生成します。
Implementation Notes:
実装上の注意：
Although the recommendation does not include the TCP Source Port, this is very implementation specific. It might be successfully included in some variants.
勧告は、TCP送信元ポートが含まれていませんが、これは非常に実装固有のものです。それは成功し、いくつかの亜種に含まれている場合があります。
The Responder Cookie depends on the TCP Sequence and Acknowledgment Numbers as they will appear for future verification. The Sequence Number will be the Initial Sequence
彼らは将来の検証のために表示されるようレスポンダクッキーは、TCPシーケンスおよび確認応答番号に依存します。シーケンス番号は、初期シーケンスになります
Number (ISN) plus one (1) for its <SYN> that will be acknowledged. The Acknowledgment Number will be the Initial Sequence Number (ISN) plus one (1) for the <SYN> that it is now acknowledging.
その<SYN>認知されるそのための番号（ISN）プラスワン（1）。謝辞番号は<SYN>それが今認めていることのための初期シーケンス番号（ISN）プラス1（1）になります。
The (32-bit) TCP Timestamps standard option MAY change to the larger 64-bit (or 128-bit) extended form; only the least significant 32 bits are included. The Initiator Timestamp field value MAY increment during the exchange; it MUST NOT be included.
（32ビット）TCPタイムスタンプ標準オプションは、より大きい64ビット（または128ビット）拡張形態に変化させてもよいです。唯一の最下位32ビットが含まれています。イニシエータタイムスタンプフィールドの値が交換中にインクリメントしてもよい（MAY）。それは含んではいけません。
The secret value is included twice to better protect against pre-calculated attacks using substitutions for variable length data. Some examples using this technique are IP-MAC and H-MAC, and it is likely that existing code could be shared.
秘密の値は、より優れた可変長データの置換を使用して事前に計算された攻撃から保護するために二回含まれています。この技術を使用していくつかの例は、IP-MACおよびH-MACであり、既存のコードを共有することができたと思われます。
The Responder SHOULD designate a (fixed or randomly selected) bit of its cookie to distinguish each changed secret value. The bit is set to a (fixed or randomly selected) constant 0 or 1, and checked upon receipt before further verification. This ensures that only one verification calculation is necessary (on average) during Denial of Service (DoS) attacks.
レスポンダは、各変更秘密値を区別するために、そのクッキーの（固定またはランダムに選択）ビットを指定するべきです。ビットは、（固定またはランダムに選択された）定数0または1に設定され、さらに検証する前に、受信時に検査されます。これが唯一の検証計算は、サービス拒否（DoS）攻撃の間に（平均的に）必要であることを保証します。
If a Responder Cookie is identical to the Initiator Cookie, the Responder SHOULD change one or more bits of its cookie to prevent its accidental appearance as a reflection attack.
レスポンダクッキーがイニシエータクッキーと同一の場合、Responderは反射攻撃などの不慮の出現を防ぐために、そのクッキーの1つのまたは複数のビットを変更する必要があります。
Each Responder maintains up to two secret values concurrently for efficient secret rollover. Each secret value has 4 states:
各Responderは同時に、効率的な秘密のロールオーバーのための2つの秘密の値まで維持しています。それぞれの秘密の値が4つの状態があります。
Generating Generates new Responder-Cookies, but not yet used for primary verification. This is a short-term state, typically lasting only one Round Trip Time (RTT).
生成は、新しいレスポンダ・クッキーを生成しますが、まだ主要な検証に使用されていません。これは、一般的に一つだけのラウンドトリップ時間（RTT）を持続、短期的な状態です。
Primary Used both for generation and primary verification.
原発は、両方の世代とプライマリ検証のために使用します。
Retiring Used for verification, until the first failure that can be verified by the newer Generating secret. At that time, this cookie's state is changed to Secondary, and the Generating cookie's state is changed to Primary. This is a short-term state, typically lasting only one RTT.
新しい生成の秘密によって検証することができる最初の障害になるまで、検証に使用引退。当時、このクッキーの状態がセカンダリに変更され、生成クッキーの状態がプライマリに変更されます。これは、一般的に一つだけRTTを持続、短期的な状態です。
Secondary Used for secondary verification, after primary verification failures. This state lasts no more than twice the Maximum Segment Lifetime (2MSL). Then, the secret is discarded.
セカンダリがプライマリ検証が失敗した後、二次検証のために使用します。この状態が2倍を超えない最大セグメント寿命（2MSL）が続きます。その後、秘密は破棄されます。
Implementation Notes:
実装上の注意：
Care MUST be taken to ensure that any expired secrets are promptly wiped from memory, and secrets are never saved to external storage.
ケアは、期限切れの秘密は速やかにメモリから拭いていることを保証するために取らなければならない、そして秘密が外部ストレージに保存されることはありません。
The first secret after initialization begins in Primary state. The system might have shutdown and restarted rapidly during the previous first secret. Thus, the first secret MUST be partially time dependent, to ensure that it differs from previous first secrets, usually by appending a time to lengthen the first secret. Those that are not the first secret SHOULD NOT include the time.
初期化後の最初の秘密は、プライマリ状態で開始されます。システムがシャットダウンを持っているし、前の第1の秘密の間に急速に再起動することがあります。このように、第1の秘密は、それは通常、第1の秘密を長くするための時間を追加することによって、先の第1の秘密とは異なることを保証するために、部分的に時間依存でなければなりません。第1の秘密でないものは、時間を含めるべきではありません。
At the same time, there is no TCP TIME-WAIT requirement before accepting connections, and there may be pent up demand for a busy service. Also, there may be outstanding datagrams attempting to complete an earlier cookie exchange. The first secret is likely to be the weakest, as no recent entropy has been included.
同時に、接続を受け入れる前にはTCP TIME-WAIT要件が存在しない、と忙しいサービスに対する需要がうっ積することができます。また、以前のクッキー交換を完了しようとする優れたデータグラムがあるかもしれません。第1の秘密は何も最近のエントロピーが含まれていないとして、最も弱い可能性があります。
Therefore, while terminating outstanding exchanges with the first secret, a new Generating secret SHOULD be created after no more than one Maximum Segment Lifetime (1MSL). Subsequent secrets SHOULD be generated at the usual rate (typically 600 seconds).
したがって、第1の秘密と抜群の交流を終了する一方で、新しい生成の秘密はありません複数の最大セグメント寿命（1MSL）の後に作成する必要があります。後続の秘密は通常のレート（通常は600秒）で生成されるべきです。
The implementation SHOULD continually gather additional entropy from checksums, cookies, timestamps, and packet arrival timing.
実装は継続的にチェックサム、クッキー、タイムスタンプ、およびパケットの到着タイミングから追加のエントロピーを収集する必要があります。
A successful option exchange signals availability of additional features.
成功したオプションの交換は、追加機能の利用可能性を通知します。
The Cookie exchange MAY be initiated at any time, limited only by the frequency of the timestamp clock.
クッキー交換はタイムスタンプクロックの周波数によって制限され、いつでも開始することができます。
If the TCB exists from a prior (or ongoing) connection, the timestamp MUST be incremented in the option.
TCBは、前（または継続）接続から存在している場合、タイムスタンプはオプションでインクリメントされなければなりません。
The Initiator generates its unpredictable cookie value, and includes the Cookie option.
イニシエータは、その予測不可能なクッキーの値を生成し、Cookieのオプションが含まれています。
During the initial exchange, the Initiator is solely responsible for retransmission. Although the cookie and sequence have not changed, each retransmission appears to the Responder as another original <SYN>.
最初の交換中、イニシエータは、再送信のために責任があります。クッキーとシーケンスが変更されていないものの、各再送は、<SYN>別の元とレスポンダに表示されます。
Implementation Notes:
実装上の注意：
Sending the <SYN> SHOULD NOT affect any existing TCB. This allows an additional RTT for duplicate or out-of-sequence segments to drain.
<SYN>送信すると、既存のTCBに影響はありません。これは、重複またはアウトオブシーケンスセグメントがドレインに追加のRTTを可能にします。
The new TCB information SHOULD be temporarily cached until a valid matching <SYN,ACK(SYN)> arrives. Then, any old TCB values are replaced.
新しいTCB情報を一時的に有効なマッチング<SYN、ACK（SYN）>までキャッシュされるべき到着。その後、任意の古いTCB値が置き換えられます。
Upon receipt of the <SYN> with a Cookie option, the Responder determines whether there are sufficient resources to begin another connection.
クッキーオプション付きの<SYN>を受信すると、レスポンダは別の接続を開始するのに十分なリソースがあるか否かを判断します。
If the TCB exists from a prior (or ongoing) connection, the timestamp MUST be incremented in the option.
TCBは、前（または継続）接続から存在している場合、タイムスタンプはオプションでインクリメントされなければなりません。
Each Sequence Number MUST be randomized [RFC1948].
各シーケンス番号は、[RFC1948]をランダム化しなければなりません。
The Responder generates its unpredictable cookie value, and includes the Cookie option.
Responderはその予測不可能なクッキーの値を生成し、Cookieのオプションが含まれています。
As the Responder retains no TCB state, retransmission timers are not available. Arrival of an Initiator's retransmission appears to be an original <SYN> transmission. There are no differences in processing.
Responderが何のTCBの状態を保持しないので、再送信タイマーは使用できません。イニシエータの再送信の到着は、元の<SYN>トランスミッションであるように思われます。処理に違いはありません。
Implementation Notes:
実装上の注意：
Sending the <SYN,ACK(SYN)> MUST NOT affect any existing TCB. This allows an additional RTT for duplicate or out-of-sequence segments to drain.
送信<SYN、ACK（SYN）を>既存のTCBに影響してはいけません。これは、重複またはアウトオブシーケンスセグメントがドレインに追加のRTTを可能にします。
This also inhibits third parties from disrupting communications.
また、これは中断する通信から第三者を阻害します。
Upon receipt of the <SYN,ACK(SYN)> with a Cookie option, the Initiator validates its cookie, timestamp, and corresponding Acknowledgment Number. The existing TCB is updated as necessary.
クッキー・オプションと<SYN、ACK（SYN）>を受信すると、イニシエータは、そのクッキー、タイムスタンプを検証し、確認応答番号に対応します。既存のTCBは、必要に応じて更新されます。
All Initiator <SYN> options are always retransmitted on this first <ACK(SYN)>, allowing the Responder to validate its cookie and establish its state.
すべてのイニシエータ<SYN>オプションが常にResponderはそのクッキーを検証し、その状態を確立することができ、この最初の<ACK（SYN）>で再送信されます。
This segment contains both Timestamps and Cookie-Pair options.
このセグメントは、タイムスタンプとクッキーペアの両方のオプションが含まれています。
The Initiator sends the Timestamps extended option with an appropriate Size -- chosen by a configurable parameter, or automatically based on its analysis of the bandwidth-delay product discovered through the RTT of its <SYN> timestamp. When the chosen Size is greater than 32 bits, the Initiator adds a random prefix to its own timestamp, and a random prefix to the Responder timestamp echo reply.
イニシエータは、適切なサイズとタイムスタンプ拡張オプションを送ります - 設定可能なパラメータによって選ばれた、または自動的に<SYN>タイムスタンプのRTTによって発見された帯域幅遅延積の分析に基づきます。選択されたサイズが32ビットよりも大きい場合、イニシエータはレスポンダタイムスタンプエコー応答に独自のタイムスタンプにランダムプレフィックス、及びランダムプレフィックスを付加します。
Implementation Notes:
実装上の注意：
A Responder Cookie identical to the Initiator Cookie MUST be discarded. This is usually an indication of a Monkey in the Middle (MITM) reflection attack or a seriously misconfigured network, and SHOULD be logged.
イニシエータクッキーと同一のレスポンダのクッキーを捨てなければなりません。これは通常、ミドル（MITM）反射攻撃または深刻な設定ミスネットワークにおけるサルの指標であり、ログに記録します。
Upon receipt of the <ACK(SYN)> with a Cookie-Pair option, the Responder validates its cookie, timestamp, and corresponding Acknowledgment Number, and establishes state for the connection. Any existing TCB is updated as necessary.
クッキーペアオプションと<ACK（SYN）>を受信すると、レスポンダは、そのクッキー、タイムスタンプを検証し、確認応答番号に対応し、接続の状態を確立します。既存のTCBは、必要に応じて更新されます。
This segment contains both Timestamps and Cookie-Pair options.
このセグメントは、タイムスタンプとクッキーペアの両方のオプションが含まれています。
However, the Responder MAY refuse to negotiate the larger 64-bit (or 128-bit) Timestamps extended option by returning the least significant bits in a smaller Timestamps extended option.
しかしながら、レスポンダは、より小さなタイムスタンプ拡張オプションの最下位ビットを返すことによって、より大きな64ビット（128ビット）のタイムスタンプ拡張オプションを交渉するために拒否することができます。
Implementation Notes:
実装上の注意：
An <ACK(SYN)> that fails to validate MUST be discarded, and SHOULD be logged.
検証に失敗した<ACK（SYN）が>捨てなければなりません、そしてログを取ります。
TCP allows two parties to simultaneously initiate the connection. Both parties send and receive an original <SYN> without an intervening <SYN,ACK(SYN)> (see [RFC793] section 3.4 and Figure 8). Each party receives a Cookie for a <Source Address, Source Port, Destination Address, Destination Port> connection that has also issued a Cookie.
TCPは、両当事者が同時に接続を開始することができます。両当事者は、送信し（[RFC793]セクション3.4および図8を参照）介在<SYN、ACK（SYN）>なし<SYN>原稿を受け取ります。各当事者は、<送信元アドレス、送信元ポート、宛先アドレス、宛先ポート>また、クッキーを発行している接続用のクッキーを受け取ります。
This condition will be unusual. The Source Port SHOULD be randomized [RFC5452], and SHOULD be chosen to differ from the Destination Port. In particular, the Source Port SHOULD be greater than 1024, preventing intervening network equipment from incorrectly classifying the return traffic. The Destination Port is most likely to be a well-known port less than 1024 [RFC3232].
この条件は珍しいだろう。送信元ポートは、[RFC5452]をランダム化されるべきであり、宛先ポートは異なるように選択する必要があります。具体的には、送信元ポートが誤っリターントラフィックを分類から介在するネットワーク機器を防ぎ、1024年よりも大きくなければなりません。宛先ポートは、よく知られているポート1024未満[RFC3232]である可能性が最も高いです。
In the event that these protections are insufficient, the conflict is resolved in an orderly fashion:
これらの保護が不十分であることをイベントでは、競合が整然と解決されます。
a. The lesser TCP Port number becomes the Responder;
A。低いTCPポート番号は、レスポンダになり、
b. The lesser IP Address becomes the Responder;
B。低いIPアドレスは、レスポンダになり、
c. The lesser Cookie becomes the Responder;
C。より少ないクッキーはレスポンダなります。
d. All of the above being equal, there is an egregiously insufficient source of randomness, but both Initiators are probably present on the same host: the lesser TCB memory address becomes the Responder.
D。等しい上記の全ては、ランダム性の著しく不十分なソースがあるが、両方の開始剤は、おそらく同じホスト上に存在している：より少ないTCBメモリアドレスがレスポンダとなります。
The Initiator silently discards the simultaneous <SYN>. The Responder revises its Cookie option, and sends the <SYN,ACK(SYN)> as usual, but without removing its existing TCB.
イニシエータは黙っ<SYN>同時を破棄します。 Responderはそのクッキーオプションを修正し、いつものように、<SYN、ACK（SYN）>送信しますが、その既存のTCBを削除せずに。
Implementation Notes:
実装上の注意：
This is usually an indication of a Monkey in the Middle (MITM) reflection attack or a seriously misconfigured network, and SHOULD be logged.
これは通常、ミドル（MITM）反射攻撃または深刻な設定ミスネットワークにおけるサルの指標であり、ログに記録します。
Support for accelerated close is REQUIRED. Accelerated close relies on the presence of cookies and timestamps. This provides improved synchronization and protection against replay attacks.
加速近くのサポートが必要です。加速近くには、クッキーとタイムスタンプの存在に依存しています。これは、リプレイ攻撃に対する改良された同期と保護を提供します。
Either party MAY close with <FIN> at any time. This <FIN> SHOULD be sent with the final data segment.
いずれの当事者は、いつでも<FIN>で閉じます。これは、<FIN>最後のデータセグメントで送信されるべきです。
This segment contains both Timestamps and Cookie-Pair options.
このセグメントは、タイムスタンプとクッキーペアの両方のオプションが含まれています。
When all segments preceding the <FIN> have been processed and acknowledged, each party SHOULD acknowledge the <FIN>.
とき<FIN>の前のすべてのセグメントは、各当事者が<FIN>を認めるべきで、処理され、承認されています。
In general, <FIN> is treated as advisory. A persistent connection can be rapidly re-established. This also inhibits third parties from disrupting communications.
一般的に、<FIN>顧問として扱われます。永続的な接続が急速に再確立することができます。また、これは中断する通信から第三者を阻害します。
Rapidly closing the connection expedites removing Responder state. Any <FIN> bearing segment SHOULD terminate delayed <ACK> [RFC5681]. Retransmit at the latest Timestamps estimated Smoothed Round Trip Time (SRTT). Backoff SHOULD NOT be used for <FIN> bearing retransmissions [RFC2988].
急速に接続を閉じると、レスポンダの状態を取り除く迅速。任意の<FIN>軸受セグメントは、遅延<ACK> [RFC5681]を終了すべきです。平滑化往復時間（SRTT）を推定し、最新のタイムスタンプで再送信します。バックオフは、<FIN>ベアリングの再送信[RFC2988]には使用しないでください。
As the Responder retains no TCB state after closing, a successful option exchange signals the Initiator will be responsible for handling TIME-WAIT state. (For previous proposal and rationale, see [FTY1999] section 3.)
Responderが閉じた後に何のTCBの状態を保持しないので、成功したオプションの交換は、イニシエータがTIME-WAIT状態を処理するための責任を負うことになります信号。 （以前の提案と理論的根拠は、[FTY1999]セクション3を参照）
A new Cookie exchange MAY be initiated at any time. This facilitates persistent connections through intervening network equipment.
新しいクッキー交換はいつでも開始することができます。これは、介在するネットワーク機器を通じて持続的な接続を容易にします。
Upon receipt of the Initiator <FIN> (and verification of the Timestamps and Cookie-Pair options), the Responder sends its <FIN,ACK(FIN)> unless there is additional data pending. In the latter case, the <FIN> is ignored until the data has been processed and acknowledged.
保留中の追加のデータが存在しない限り、イニシエータ<FIN>（及びタイムスタンプとクッキー対オプションの検証）を受信すると、レスポンダは、その<FIN、ACK（FIN）を>送信します。データが処理され、肯定応答されるまで、後者の場合には、<FIN>が無視されます。
Upon receipt of the Responder <FIN,ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Initiator sends its final <ACK(FIN)> unless there is additional data pending. The Initiator enters TIME-WAIT state.
レスポンダ<FIN、ACK（FIN）>（とタイムスタンプとクッキーペアオプションの検証）を受信すると、イニシエータは、保留中の追加データがその最終<ACK（FIN）>しない限り、送信します。イニシエータは、TIME-WAIT状態になります。
This segment contains both Timestamps and Cookie-Pair options.
このセグメントは、タイムスタンプとクッキーペアの両方のオプションが含まれています。
Upon receipt of the Initiator <ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Responder removes its TCB.
イニシエータ<ACK（FIN）>（とタイムスタンプとクッキーペアオプションの検証）を受信すると、レスポンダは、そのTCBを除去します。
Upon arrival of more data prompting a new Cookie exchange, the Initiator SHOULD NOT send a final <ACK(FIN)> and/or SHOULD NOT wait the remaining TIME-WAIT interval. Any existing TSoffset SHOULD be incremented. TSoffset will be removed (with the TCB itself) at the conclusion of a future TIME-WAIT state.
新しいクッキー交換を促すより多くのデータが到着すると、イニシエータは、最終的な<ACK（FIN）>を送るべきではありませんおよび/または残りTIME-WAITインターバルを待つべきではありません。既存のTSoffsetはインクリメントしなければなりません。 TSoffset将来TIME-WAIT状態の終了時（TCB自体で）除去されます。
Upon receipt of the Responder <FIN> (and verification of the Timestamps and Cookie-Pair options), the Initiator sends its <FIN,ACK(FIN)> unless there is additional data pending. In the latter case, the <FIN> is ignored until the data has been processed and acknowledged.
保留中の追加のデータが存在しない限り、レスポンダ<FIN>（及びタイムスタンプとクッキー対オプションの検証）を受信すると、イニシエータは、その<FIN、ACK（FIN）を>送信します。データが処理され、肯定応答されるまで、後者の場合には、<FIN>が無視されます。
Upon receipt of the Initiator <FIN,ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Responder sends its final <ACK(FIN)> and removes its TCB.
イニシエータ<FIN、ACK（FIN）>（とタイムスタンプとクッキーペアオプションの検証）を受信すると、レスポンダは、その最終的な<ACK（FIN）>を送信し、そのTCBを除去します。
This segment contains both Timestamps and Cookie-Pair options.
このセグメントは、タイムスタンプとクッキーペアの両方のオプションが含まれています。
If the Responder's final <ACK(FIN)> is lost, the Responder is likely to send a <RST> (as the Responder retains no TCB state). This distinguished <RST> SHOULD copy both Timestamps and Cookie-Pair options.
レスポンダの最後の<ACK（FIN）が>失われた場合、Responderは<RST>（Responderは何TCBの状態を保持していないもの）を送信する可能性があります。この区別<RST>タイムスタンプとクッキーペアの両方のオプションをコピーする必要があります。
Upon receipt of the Responder's final <ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Initiator enters TIME-WAIT state.
レスポンダの最後の<ACK（FIN）>を受信すると（とタイムスタンプとクッキーペアオプションの検証）、開始剤はTIME-WAIT状態に入ります。
Upon arrival of more data prompting a new Cookie exchange, the Initiator SHOULD NOT send a <FIN,ACK(FIN)> and/or SHOULD NOT wait the remaining TIME-WAIT interval. Any existing TSoffset SHOULD be incremented. TSoffset will be removed (with the TCB itself) at the conclusion of a future TIME-WAIT state.
新しいクッキー交換を促すより多くのデータが到着すると、イニシエータは<FIN、ACK（FIN）>を送るべきではありませんおよび/または残りTIME-WAITインターバルを待つべきではありません。既存のTSoffsetはインクリメントしなければなりません。 TSoffset将来TIME-WAIT状態の終了時（TCB自体で）除去されます。
Support for accelerated open is OPTIONAL.
加速オープンのためのサポートはオプションです。
When an application is capable of idempotent transactions (such as a query that returns a consistent result or service response heading), the application sets the appropriate limit separately for each port or connection. Applications are responsible for ensuring that retransmissions do not cause duplication of data.
アプリケーションは、（例えば、一貫した結果またはサービス応答の見出しを返すクエリなど）冪等取引が可能である場合、アプリケーションは、各ポートまたは接続のために別々に適切な制限を設定します。アプリケーションは、再送信は、データの重複を引き起こさないことを保証する責任があります。
This facility allows single data segment transactions without establishing TCB state at the Responder (server). For longer transactions, a short look-ahead of upcoming data allows the Initiator (client) to select alternatives for further processing.
この機能は、レスポンダ（サーバ）でTCBの状態を確立することなく、単一のデータ・セグメント・トランザクションを可能にします。長いトランザクションでは、今後のデータの短い先読みは、イニシエータ（クライアント）はさらなる処理のための選択肢を選択することができます。
By default, the Initiator <SYN> does not contain data. The application sets the TCP_SYN_DATA_LIMIT to indicate that the <SYN> MAY be sent with data.
デフォルトでは、イニシエータは、<SYN>データが含まれていません。アプリケーションは、<SYN>データを送信することができることを示すためにTCP_SYN_DATA_LIMITを設定します。
The Responder Maximum Segment Size (MSS) is unknown, and the default MSS (536 bytes) MUST be used instead ([RFC1122] section 4.2.2.6). This is further reduced by the total length of the TCP options (in this case, commonly 496 bytes). Applications MAY specify a shorter limit.
レスポンダ最大セグメントサイズ（MSS）が不明であり、デフォルトMSS（536バイト）（[RFC1122]セクション4.2.2.6）を代わりに使用しなければなりません。これはさらに、TCPオプションの合計の長さ（この場合、一般的に496バイト）だけ減少します。アプリケーションは、短い制限を指定するかもしれません。
If the data will not entirely fit within the initial segment, data MUST NOT be sent until after the Responder's <SYN,ACK(SYN)> is received.
最初のセグメント内のデータは完全に収まらない場合は、データがレスポンダの<SYN、ACK（SYN）が>受信後まで送ってはいけません。
Unlike T/TCP [RFC1644], <FIN> SHOULD NOT be sent with <SYN> data. This facilitates persistent connections.
T / TCP [RFC1644]とは異なり、<FIN> <SYN>データを送るべきではありません。これは、持続的な接続を容易にします。
Likewise, <PSH> SHOULD NOT be set. Although the application might use push to indicate that its data is ready to send, the push is implied for <SYN> data segments.
同様に、<PSH>は設定しないでください。アプリケーションはそのデータを送信する準備ができていることを示すためにプッシュを使用する場合がありますが、プッシュは、<SYN>データ・セグメントのために暗示されています。
During the initial exchange, the Initiator is solely responsible for retransmission. Although the cookie and sequence have not changed, each retransmission appears to the Responder as another original <SYN>.
最初の交換中、イニシエータは、再送信のために責任があります。クッキーとシーケンスが変更されていないものの、各再送は、<SYN>別の元とレスポンダに表示されます。
Implementation Notes:
実装上の注意：
Initiator <SYN,FIN> with the Cookie option and no segment data is permitted in a test environment. This combination SHOULD be silently discarded.
クッキー・オプションとデータをテスト環境で許可されてないセグメントとイニシエータ<SYN、FIN>。この組み合わせは静かに捨てられるべきです。
Initiator <SYN,FIN> with both the Cookie option and segment data is similar to T/TCP [RFC1644]. However, whenever the Responder <SYN,ACK(SYN),FIN> has been sent with data (there is no further data expected), TCB state has not been saved at the Responder. There is no need to send <FIN> to close the connection.
クッキーオプションとセグメントの両方を有する開始剤<SYN、FIN>データは、T / TCP [RFC1644]と同様です。しかしながら、レスポンダ<SYN、ACK（SYN）、FIN>がデータと共に送信されたときに（予想さらなるデータが存在しない）、TCB状態がレスポンダに保存されていません。接続を閉じるには、<FIN>を送信する必要はありません。
By default, the Responder <SYN,ACK(SYN)> does not contain data. The application sets the TCP_SYN_ACK_DATA_LIMIT to indicate that the <SYN,ACK(SYN)> MAY be sent with data.
デフォルトでは、レスポンダ<SYN、ACK（SYN）が>データが含まれていません。アプリケーションは<SYN、ACK（SYN）>ことを示すTCP_SYN_ACK_DATA_LIMITを設定データを用いて送信することができます。
Segment data is limited to the Maximum Transmission Unit (MTU). Applications MAY specify a shorter limit to prevent spoofed amplification and reflection attacks [RFC5358].
セグメント・データは、最大伝送単位（MTU）に制限されます。アプリケーションは、偽装された増幅および反射攻撃を防ぐために、短い制限[RFC5358]を指定するかもしれません。
Upon receipt of the <SYN> with a Cookie option, the Responder MAY process any data present. If the initial data is not accepted, the Acknowledgment Number will be the received Sequence Number plus one (1) for the <SYN>.
クッキー・オプションと<SYN>を受信すると、レスポンダは、任意のデータが存在し処理することができます。初期データが受け入れられない場合、肯定応答番号が受信されたシーケンス番号と<SYN>のための1つの（1）となります。
If the segment data is the entire response (there is no further data expected), <FIN> MAY be set.
セグメントデータ全体応答である場合（予想さらなるデータが存在しない）、<FIN>が設定されてもよいです。
However, <PSH> SHOULD NOT be set. Although the application might use push to indicate that its data is ready to send, the push is implied for <FIN> data segments (see [RFC793] section 3.7, page 41).
しかし、<PSH>は設定しないでください。アプリケーションがそのデータを送信する準備ができていることを示すためにプッシュを使用するかもしれないが、プッシュは、（[RFC793]セクション3.7、ページ41を参照）<FIN>データセグメントについて暗示されます。
As the Responder retains no TCB state, retransmission timers are not available. Arrival of an Initiator's retransmission appears to be an original <SYN> transmission. There are no differences in processing.
Responderが何のTCBの状態を保持しないので、再送信タイマーは使用できません。イニシエータの再送信の到着は、元の<SYN>トランスミッションであるように思われます。処理に違いはありません。
Implementation Notes:
実装上の注意：
The Responder Cookie depends on the TCP Sequence and Acknowledgment Numbers after processing <SYN>. Therefore, neither will include data.
レスポンダクッキーは、<SYN>処理した後、TCPシーケンスおよび確認応答番号に依存します。したがって、どちらもデータが含まれません。
Upon receipt of the <SYN,ACK(SYN)> with a Cookie option, the Initiator MAY process any data present. In this case, the internal RCV.NXT is advanced to provide at-most-once semantics.
クッキー・オプションと<SYN、ACK（SYN）>を受信すると、イニシエータは、任意のデータが存在し処理することができます。この場合、内部RCV.NXTはで最大1回のセマンティクスを提供するために進んでいます。
If the segment data is the entire response (there is no further data expected), the Initiator enters TIME-WAIT state.
セグメントデータ全体応答（期待される更なるデータが存在しない）である場合、イニシエータは、TIME-WAIT状態に入ります。
Otherwise, original <SYN> data is retransmitted in <ACK(SYN)>, as its processing is optional. The Acknowledgment Number will be the received Sequence Number plus one (1) for the <SYN>. The Sequence Number will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>.
その処理はオプションであるようにそうでなければ、元の<SYN>データは、<ACK（SYN）>で再送されます。確認応答番号が受信されたシーケンス番号と<SYN>のための1つの（1）となります。シーケンス番号は<SYN>のための初期シーケンス番号（ISN）プラス1（1）になります。
Unlike T/TCP [RFC1644], there is no implicit acknowledgment.
T / TCP [RFC1644]とは異なり、暗黙の確認はありません。
If the Selective Acknowledgment (Sack) option [RFC2018] has been successfully negotiated, a short Sack acknowledging the response data MAY be sent following the Cookie-Pair in the extended header.
選択的確認応答（袋）オプション[RFC2018]が正常にネゴシエートされた場合、応答データを承認短い袋が拡張ヘッダにクッキーペア以下送信されるかもしれません。
At this time, any second segment may be sent without awaiting an <ACK>, according to the usual [RFC5681] TCP congestion control process.
このとき、任意の第二セグメントは、通常、[RFC5681] TCPの輻輳制御処理によれば、<ACK>待たずに送信されてもよいです。
Implementation Notes:
実装上の注意：
Upon arrival of more data prompting a new Cookie exchange, there is no need to increment the previous timestamp; TCB state has not been saved at the Responder. Instead, use the saved RCV.NXT, plus one (1) for the (actual or implied) <FIN>.
新しいクッキー交換を促すより多くのデータが到着すると、前のタイムスタンプをインクリメントする必要はありません。 TCBの状態はレスポンダで保存されていません。代わりに、保存されたRCV.NXTを使用し、プラス1（1）（実際または暗示）のための<FIN>。
Initiator <ACK(SYN),FIN> with the Cookie-Pair option and no segment data is never required; TCB state has not been saved at the Responder. This combination MUST be silently discarded.
クッキーペアオプションとないセグメント・データとイニシエータ<ACK（SYN）、FIN>が必要とされることはありません。 TCBの状態はレスポンダで保存されていません。この組み合わせは静かに捨てなければなりません。
Upon receipt of the <ACK(SYN)> with a Cookie-Pair option (and verification of the Timestamps and Cookie-Pair options), the Responder SHOULD process any data present.
クッキーペアオプション（及びタイムスタンプとクッキーペアオプションの検証）と<ACK（SYN）>を受信すると、レスポンダは、任意のデータの存在を処理しなければなりません。
Since the TCP Sequence and Acknowledgment Numbers have not advanced, the Responder will process the same incoming data, and transmit the same response.
TCPシーケンスおよび確認応答番号が進んでいないので、Responderは同じ着信データを処理し、同じ応答を送信します。
If the Selective Acknowledgment (Sack) option [RFC2018] has been successfully negotiated, with a short Sack covering earlier response data, only additional unacknowledged response data is sent.
選択的確認応答（袋）オプション[RFC2018]が正常にネゴシエートされた場合、以前の応答データをカバーする短い袋と、唯一の追加未確認応答データが送信されます。
At this time, any second segment may be sent without awaiting an <ACK>, according to the usual [RFC5681] TCP congestion control process.
このとき、任意の第二セグメントは、通常、[RFC5681] TCPの輻輳制御処理によれば、<ACK>待たずに送信されてもよいです。
When a TCB with matching Addresses and Ports is found, but the Cookie-Pair fails to verify, the datagram MUST be silently discarded.
一致するアドレスとポートとTCBが見つかったが、クッキーペアが検証に失敗した場合、データグラムは静かに捨てなければなりません。
When no TCB with matching Addresses and Ports is found, a <RST> is sent as usual. The Timestamps option SHOULD be copied [RFC1323]. A Cookie-Pair option MUST also be copied. The Cookie option (or Cookie-less option) MUST NOT be copied.
一致するアドレスとポートとはTCBが見つからない場合、<RST>通常通り送られます。タイムスタンプオプションは、[RFC1323]をコピーする必要があります。クッキーペアオプションもコピーされなければなりません。クッキーオプション（またはクッキーレスオプション）は、コピーしてはいけません。
Any <RST> is always treated as advisory. A <RST> without a matching Cookie-Pair option could be caused by antique duplicates. Receipt has no effect on the operation of the protocol. The implementation SHOULD continue until a USER TIMEOUT expires. (See [RFC5482] for additional information.)
どれ<RST>は常に助言として扱われます。マッチングクッキーペアオプションなし<RST>は、アンティークの重複が原因である可能性があり。領収書は、プロトコルの動作には影響を与えません。ユーザのタイムアウトの有効期限が切れるまでの実装は続けるべきです。 （詳細については、[RFC5482]を参照）。
This also inhibits third parties from disrupting communications.
また、これは中断する通信から第三者を阻害します。
A successful Cookie (or Cookie-less) option exchange signals availability of the TCP header extension. Other options with large data portions MAY also use this feature. The extended option data is processed in the order that the options appear.
成功したクッキー（またはクッキーレス）TCPヘッダ拡張のオプション交換信号の可用性。大規模なデータ部分と他のオプションも、この機能を使用するかもしれません。拡張オプションデータはオプションが表示される順序で処理されます。
(Kind 5 [RFC2018].) The pairs of 32-bit fields are well suited to the header extension. Because of its variable size, this is RECOMMENDED as the final extended option.
（5種類[RFC2018]）。32ビットフィールドのペアは、ヘッダ拡張に適しています。理由は、その可変サイズの、これが最後の拡張オプションとして推奨されます。
During the cookie exchange, the <ACK(SYN)> MAY include this option to acknowledge any optional transaction response data.
クッキー交換時には、<ACK（SYN）は>任意のオプションのトランザクション応答データを確認するには、このオプションを含むかもしれません。
(Kind 8 [RFC1323].) Support is REQUIRED. See also section 3.
（種類8 [RFC1323]）のサポートが必要です。また、セクション3を参照してください。
When a segment needs no header extension, and 32-bit timestamps have been negotiated, this option MUST be sent.
セグメントは全くヘッダ拡張を必要としない、32ビットのタイムスタンプがネゴシエートされている場合、このオプションを送らなければなりません。
(Kinds 11-13 [RFC1644].) Incompatible with this specification, and MUST be ignored on receipt.
この仕様と互換性がない（種類11-13 [RFC1644]）、及び領収書の上で無視しなければなりません。
(Kind 19 [RFC2385].) This option is beyond the scope of this specification. Because specific configuration is required, sending is under the complete control of the operator. Segments lacking this option will be silently discarded.
（種類19 [RFC2385]。）このオプションは、この明細書の範囲外です。特定の構成が必要なので、送信は、オペレータの完全な制御下にあります。このオプションを欠くセグメントは黙って破棄されます。
The size of the option itself precludes use with the Cookie option in the <SYN>. Regardless of the system default, the Cookie option MUST NOT be sent, and MUST be ignored on receipt. Instead, the Cookie-less extension option indicates that other features of this specification are available.
オプション自体の大きさは、<SYN>でクッキーオプションで使用を排除します。かかわらず、システムのデフォルトの、クッキーオプションを送ってはいけませんし、領収書で無視しなければなりません。その代わり、クッキーレス拡張オプションは、この仕様書の他の機能が利用可能であることを示しています。
(Kind 29 [RFC5925].) This option is beyond the scope of this specification. Because specific configuration is required, sending is under the complete control of the operator. Segments lacking this option will be silently discarded.
（種類29 [RFC5925]。）このオプションは、この明細書の範囲外です。特定の構成が必要なので、送信は、オペレータの完全な制御下にあります。このオプションを欠くセグメントは黙って破棄されます。
The size of the option itself precludes use with the Cookie option in the <SYN>. Regardless of the system default, the Cookie option MUST NOT be sent, and MUST be ignored on receipt. Instead, the Cookie-less extension option indicates that other features of this specification are available.
オプション自体の大きさは、<SYN>でクッキーオプションで使用を排除します。かかわらず、システムのデフォルトの、クッキーオプションを送ってはいけませんし、領収書で無視しなければなりません。その代わり、クッキーレス拡張オプションは、この仕様書の他の機能が利用可能であることを示しています。
T/TCP [RFC1379] [RFC1644] permits lightweight TCP transactions for applications that traditionally have used UDP. However, T/TCP has unacceptable security issues [Hannum1996] [Phrack1998].
T / TCP [RFC1379] [RFC1644]は、伝統的にUDPを使用しているアプリケーションのための軽量TCPトランザクションを可能にします。しかし、T / TCPは、[Hannum1996] [Phrack1998]容認できないセキュリティ上の問題があります。
The initial specification [KS1995] of Photuris [RFC2522], now called version 1 (December 1994 to March 1995), was based on a short list of design requirements, and simple experimental code by Phil Karn. A "Cookie" Exchange guards against simple flooding attacks sent with bogus IP Sources or UDP Ports.
初期仕様Photurisの[KS1995] [RFC2522]は、今、フィル・カーンによって設計要件の短いリスト、および簡単な実験的なコードに基づいていた、（1995年3月に1994年12月）バージョン1と呼ばれます。偽のIPソースまたはUDPポートに送信され、単純なフラッディング攻撃に対する「クッキーの」Exchangeガード。
During 1995, the Photuris efficient secret rollover and many other extensions were specified. Multiple interoperable implementations were produced.
1995年の間に、Photuris効率的な秘密のロールオーバーおよび他の多くの拡張機能が指定されました。複数の相互運用可能な実装を作製しました。
By September 1996, the long anticipated Denial of Service (DoS) attacks in the form of TCP SYN floods were devastating popular (and unpopular) servers and sites. Phil Karn informally mentioned adapting anti-clogging cookies to TCP. Perry Metzger proposed adding Karn's cookies as part of a "TCP++" effort [Metzger1996].
1996年9月では、TCP SYNフラッドの形で長い予想されるサービス拒否（DoS）攻撃は、人気（と不人気）サーバーやサイトを荒廃させました。フィル・カーンは、非公式にTCPに目詰まり防止のクッキーを適応述べました。ペリーメッツガーは、「TCP ++」努力[Metzger1996]の一環として、カーンのクッキーを追加することを提案しました。
Later in 1996, Daniel J. Bernstein implemented "SYN cookies", small cookies embedded in the TCP SYN Initial Sequence Number (ISN). This technique was exceptionally clever, because it did not require cooperation of the remote party and could be deployed unilaterally. However, SYN cookies can only be used in emergencies; they are incompatible with most TCP options. As there is insufficient space in the Sequence Number, the cookie is not considered cryptologically secure. Therefore, the mechanism remains inactive until the system is under attack, and thus is not well tested in operation. SYN cookies were not accepted for publication until recently [RFC4987].
その後1996年に、ダニエル・バーンスタインは、「SYNクッキー」、TCP SYN初期シーケンス番号（ISN）に埋め込まれた小さなクッキーを実装しました。それは相手の協力を必要としないと一方的に展開される可能性があるため、この技術は、非常に巧妙でした。しかし、SYNクッキーは、緊急時にのみ使用することができます。彼らは、ほとんどのTCPオプションと互換性がありません。シーケンス番号での十分なスペースがあるので、クッキーは暗号学安全と見なされていません。システムが攻撃を受けているので、うまく動作してテストされなくなるまでそのため、メカニズムが非アクティブのままです。 SYNクッキーが最近[RFC4987]まで、出版のために受け入れられませんでした。
In 1998, Perry Metzger proposed adding Karn's cookies as part of a "TCPng" discussion [Metzger1998].
1998年、ペリーメッツガーは「TCPng」の議論[Metzger1998]の一環として、カーンのクッキーを追加することを提案しました。
In 1999, Faber, Touch, and Yue [FTY1999] proposed using an option to negotiate the party that would maintain TIME-WAIT state. This permits a server to entirely eliminate state after closing a connection.
1999年には、フェーバー、タッチ、そして越[FTY1999] TIME-WAIT状態を維持するパーティーを交渉するためのオプションを使用して提案しました。これは、完全な接続を閉じた後の状態を解消するために、サーバーを許可します。
In 2000, the Stream Control Transmission Protocol (SCTP) [RFC2960] was published with an inadequate partial cookie mechanism claiming to be based upon Photuris. It featured a deficient checksum (replaced in 2002 by [RFC3309] without graceful transition), and has undergone subsequent revisions [RFC4960].
2000年に、ストリーム制御伝送プロトコル（SCTP）[RFC2960]は不十分な部分クッキー機構は、Photurisに基づくことを主張してパブリッシュされました。これは、（正常な遷移せずに[RFC3309]によって2002年に置き換え）欠損チェックサムを特色、およびその後の改訂[RFC4960]を受けました。
In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was published with a mechanism analogous to SYN cookies.
2006年には、データグラム輻輳制御プロトコル（DCCP）[RFC4340]はSYNクッキーに類似したメカニズムで公開されました。
Andre Broido informally described utilizing cookies for Transport Layer Security (TLS) session identifiers, in place of the [RFC5077] ticket. Rapid TLS session resumption would improve both latency and privacy, but is beyond the scope of this specification. Also, he provided numerous helpful comments and additional references, such as [KBC2005].
アンドレBroidoは非公式に[RFC5077]チケットの代わりに、トランスポート層セキュリティ（TLS）セッション識別子のためにクッキーを利用し説明しました。迅速なTLSセッション再開は、待ち時間とプライバシーの両方を向上させるが、この仕様の範囲を超えているでしょう。また、彼はそのような[KBC2005]として、数多くの有益なコメントや追加の参照を提供します。
H. K. Jerry Chu and Arvind Jain informally described retaining existing cookies for accelerated open on subsequent connections. That feature was subsumed by this specification.
H. K.ジェリー・チューとアービンドジャイナ教は非公式に、後続の接続でオープン加速のための既存のCookieを保持説明しました。その機能は、本明細書に包含されました。
Wesley M. Eddy and Adam Langley previously proposed another pair of options [EL2008] extending the TCP header option space.
ウェズリーM.渦とアダムラングレーは、以前にTCPヘッダオプション空間を拡張するオプションの別のペア[EL2008]を提案しました。
Adam Langley previously proposed another option [Langley2008] permitting <SYN,ACK(SYN)> constant payload data. His (August 2008) code was a base for the initial TCPCT implementation.
アダムラングレーは、以前[Langley2008 <SYN、ACK（SYN）>一定のペイロードデータを許可別のオプションを提案しました。彼（2008年8月）のコードでは、初期TCPCTの実装のための基盤でした。
Joe Touch postulated a (hopefully hypothetical) failure mode: options re-ordered by middleware. This caused a change in specifications, and has considerably complicated option interactions and processing. His helpful comments were appreciated.
オプションミドルウェアによって再注文：ジョー・タッチは（うまくいけば仮想的な）故障モードを想定しました。これは、仕様の変更を引き起こし、かなりオプションの相互作用と処理が複雑ました。彼の有益なコメントは大歓迎されました。
Many thanks to Fernando Gont for suggestions, and Rick Jones for performance testing.
パフォーマンステストのための提案のためのフェルナンドGont、そしてリック・ジョーンズに感謝します。
Two TCP Option numbers are reserved for general experimental use under the rules laid out in [RFC4727] and [RFC3692] section 1. Such values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. Experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments.
2つのTCPオプション番号は[RFC4727]とにレイアウトルールの下で一般的な実験の使用のために予約されている[RFC3692]セクション実験的使用のために予約1.このような値は、永久行われないべきん。永久的な割り当ては、標準的なプロセスを経て得られたことがなければなりません。実験の数字は、実験やテストのために意図されており、全体または一般的な展開のために意図されていません。
For further information, contact the author.
詳細については、作者に連絡。
Any implementation of this specification SHOULD be configurable, separately for each port or connection.
本明細書のいずれかの実装では、個別のポートまたは接続のために、構成可能であるべきです。
TCPCT_COOKIE_DESIRED Values: 0 (disabled), 8, 10, 12, 14, 16. Default: 16. Send the Cookie option with the <SYN>.
TCPCT_COOKIE_DESIRED値：0（無効）、8、10、12、14、16デフォルト：16. <SYN>とクッキーのオプションを送信します。
TCPCT_EXTEND_TS[32|64|128] Default: off. If defined, may designate 32-bit, 64-bit, or 128-bit timestamps extension.
TCPCT_EXTEND_TS [32 | 64 | 128]デフォルト：オフ。定義されている場合、32ビット、64ビット、または128ビットのタイムスタンプ拡張子を指定することができます。
TCPCT_IN_ALWAYS Default: off. Silently discard any incoming <SYN> that is missing the Cookie option.
TCPCT_IN_ALWAYSデフォルト：オフ。サイレントクッキーオプションが欠落しているすべての受信<SYN>を捨てます。
TCPCT_OUT_NEVER Default: off. Refuse to send (override) the Cookie option.
TCPCT_OUT_NEVERデフォルト：オフ。 （オーバーライド）クッキーのオプションを送信することを拒否。
TCP_SYN_DATA_LIMIT Default: 0. Maximum: 496. The maximum amount of data transmitted with the <SYN>. Wait for data before sending.
TCP_SYN_DATA_LIMITデフォルト：0最大：496 <SYN>で送信されるデータの最大量。送信する前にデータを待ちます。
TCP_SYN_ACK_DATA_LIMIT Default: 0. Maximum: 1220. The maximum amount of data transmitted with the <SYN,ACK(SYN)>. Wait for data before sending.
TCP_SYN_ACK_DATA_LIMITデフォルト：0最大：1220 <SYN、ACK（SYN）>で送信されるデータの最大量。送信する前にデータを待ちます。
TCPCT was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology.
TCPCTは、現在利用可能なツールに、暗号技術に興味を持つ経験豊富なネットワークプロトコル設計者によってではなく、ネットワークプロトコルに関心のある暗号技術によって基づいていました。この仕様は、暗号学で広範な背景を必要とすることなく、容易に実現可能であることが意図されています。
Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come. Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis.
そのため、最小限の背景暗号議論と論拠は、本文書に含まれています。いくつかのレビューは、一般的な暗号コミュニティによって提供されているが、設計上の決定とトレードオフは徹底的に、その後の論文で分析して来て、長年にわたって議論されることが予想されます。暗号の詳細は、より容易にかつタイムリーに新たな分析を用いて更新することができる別のドキュメント用に予約されています。
The security depends on the quality of the random numbers generated by each party. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem (see [RFC4086] for discussion).
セキュリティは、各当事者によって生成された乱数の品質に依存します。ハードウェアの支援なし汎用コンピュータ上の暗号の品質乱数を生成すると、（議論のための[RFC4086]を参照）は非常に難しい問題です。
TCPCT is not intended to prevent or recover from all possible security threats. Rather, it is designed to inhibit inadvertent middlebox interference, while protecting against Denial of Service (DoS) attacks. (See [RFC4732], and [RFC3552] section 4.6.3 et seq.)
TCPCTを防止またはすべての可能なセキュリティ上の脅威から回復するものではありません。サービス拒否（DoS）攻撃から保護しながら、むしろ、不注意ミドル干渉を抑制するように設計されています。 （[RFC4732]を参照し、[RFC3552]セクション4.6.3以降）。
The cookie exchange does not protect against an interloper that can race to substitute another value, nor an interceptor that can modify and/or replace a value. These attacks are considerably more difficult than passive vacuum-cleaner monitoring.
クッキー交換は別の値を代入することができますレース侵入、また、変更および/または値を置き換えることができインターセプタを防ぐことはできません。これらの攻撃はかなり受動的な掃除機の監視よりも困難です。
Note that each incoming <SYN,ACK(SYN)> replaces the Responder cookie. The initial exchange is most fragile, as protection against spoofing relies entirely upon the sequence and timestamp. This replacement strategy allows the correct pair to pass through, while any others will be filtered via Responder verification later.
レスポンダクッキーを置き換える各着信<SYN、ACK（SYN）>ことに留意されたいです。なりすましに対する保護は、シーケンスおよびタイムスタンプに完全に依存しているように、初期交換は、最も壊れやすいです。任意の他のものは後レスポンダ検証を介して濾過されながらこの置換戦略は、正しいペアを通過させます。
Appendix A. Example Headers
付録A.例ヘッダ
A.1. Example <SYN>
A.1。例<SYN>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=TS | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=Cookie | Length=16 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
A 14 byte (112-bit) Cookie barely fits with the other recommended options in the maximal 60 byte TCP header (40 bytes of option space).
14バイト（112ビット）クッキーはほとんど最大60バイトのTCPヘッダ内の他の推奨オプション（オプション空間の40バイト）と嵌合します。
Since the cookies are required to be the same size and meet a 32-bit alignment requirement, the implementor recognizes that this order provides optimal packing.
クッキーは、同じサイズで、32ビットのアライメントの要件を満たすために必要とされるので、実装者はこの順序が最適なパッキングを提供することを認識する。
The UserTimeOut (UTO) option can appear in other locations instead, such as following the Cookie option. Because some middleboxes are sensitive to the order of options, UTO should not appear before MSS nor between the TS and Cookie.
UserTimeOut（UTO）オプションは、クッキー・オプションを以下のように、代わりに他の場所に現れることができます。いくつかのミドルボックスは、オプションの順序に敏感であるため、UTOは、MSSの前にも、TSとクッキーの間で表示されません。
A.2. Example <ACK(SYN)> with Sack
A.2。袋は、実施例<ACK（SYN）>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=16 | 0 | S=1 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Sack | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ending Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sack implies SackOK.
袋はSackOKを意味します。
A.3. Example <ACK(SYN)> with 64-bit Timestamps
A.3。 64ビットのタイムスタンプは、実施例<ACK（SYN）>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=15 | 0 | S=2 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ TS Value +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TS Echo Reply +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The larger 64-bit (or 128-bit) Timestamps extended option MUST be recognized, although the Responder MAY return a smaller Timestamps extended option.
Responderが小さいタイムスタンプ拡張オプションを返すことができるが、より大きな64ビット（128ビット）のタイムスタンプ拡張オプションは、認識されなければなりません。
Normative References
引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948] Bellovin氏、S.、 "シーケンス番号攻撃からの保護"、RFC 1948、1996年5月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]レイノルズ、J.、エド、。：、RFC 3232、2002年1月 "割り当て番号RFC 1700は、オンラインデータベースで置き換えられます"。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5452]ヒューバート、A.とR.バンムック、RFC 5452、2009年1月 "鍛造回答に対するDNSは、より弾力性を作るための措置"。
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, March 2009.
[RFC5482]エッゲルト、L.およびF. Gont、 "TCPユーザのタイムアウト・オプション"、RFC 5482、2009年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]オールマン、M.、パクソン、V.、およびE.ブラントン、 "TCP輻輳制御"、RFC 5681、2009年9月。
Informative References
参考文献
[EL2008] Eddy, W. and A. Langley, "Extending the Space Available for TCP Options", Work in Progress, July 2008.
[EL2008]エディ、W.およびA.ラングレー、「TCPオプションのために使用可能な領域の拡張」を、進歩、2008年7月に作業。
[FTY1999] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", IEEE INFOCOM 99, pp. 1573-1584.
[FTY1999]フェーバー、T.、タッチ、J.、およびW.越、 "ビジーサーバー上のTCPとその効果でTIME-WAIT状態"、IEEE INFOCOM 99頁。1573年から1584年。
[Gont2009] Gont, F., "Security assessment of the Transmission Control Protocol (TCP)", February 2009. https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
[Gont2009] Gont、F.、 "伝送制御プロトコル（TCP）のセキュリティアセスメント"、2009年2月https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP。 PDF
[GO2010] Gont, F. and A. Oppermann, "On the generation of TCP timestamps", Work in Progress, June 2010.
[GO2010] Gont、F.およびA. Oppermannの、 "TCPタイムスタンプの生成について"、進歩、2010年6月に作業。
[Hannum1996] Hannum, C., "Security Problems Associated With T/TCP", unpublished work in progress, September 1996. http://www.mid-way.org/doc/ttcp-sec.txt
[Hannum1996] Hannum、C.、 "セキュリティの問題関連でT / TCP"、進行中の未発表作品、1996年9月http://www.mid-way.org/doc/ttcp-sec.txt
[KBC2005] Kohno, T., Broido, A., and K. C. Claffy, "Remote physical device fingerprinting", IEEE Symposium on Security and Privacy, May 2005. http://www.caida.org/ outreach/papers/2005/fingerprinting/ KohnoBroidoClaffy05-devicefingerprinting.pdf
セキュリティとプライバシー上の[KBC2005]河野、T.、Broido、A.、およびKC Claffy、 "リモート物理デバイスフィンガープリント"、IEEEシンポジウム、2005年5月http://www.caida.org/アウトリーチ/新聞/ 2005 /フィンガープリント/ KohnoBroidoClaffy05-devicefingerprinting.pdf
[KS1995] Karn, P. and W. Simpson, "The Photuris Session Key Management Protocol", March 1995.
[KS1995]カーン、P.とW.シンプソン、 "Photurisセッション鍵管理プロトコル"、1995年3月。
Published as: "Photuris: Design Criteria", Proceedings of
Sixth Annual Workshop on Selected Areas in Cryptography,
LNCS 1758, Springer-Verlag. August 1999.
[Langley2008] Langley, A., "Faster application handshakes with SYN/ACK payloads", Work in Progress, August 2008.
[Langley2008]ラングレー、A.、 "SYN / ACKペイロードとより高速なアプリケーションの握手"、進歩、2008年8月の作業。
[MAF2004] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proceedings 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004. http://www.icsi.berkeley.edu/pubs/networking/tbit-Aug2004.pdf
[MAF2004]メディナ、A.、オールマン、M.、およびS.フロイド、 "トランスポートプロトコルとのMiddleboxes間の相互作用を測定する"、インターネット測定に関する議事第四ACM SIGCOMM / USENIX会議、2004年10月のhttp：//www.icsi。 berkeley.edu/pubs/networking/tbit-Aug2004.pdf
[Metzger1996] Metzger, P., "Re: SYN floods (was: does history repeat itself?)", September 9, 1996. http://www.merit.net/mail.archives/nanog/ 1996-09/msg00235.html
[Metzger1996]メッツガー、P.、 "再：SYNフラッド（た？：歴史は繰り返すん）"、9月9日、1996年http://www.merit.net/mail.archives/nanog/ 1996年から1909年/ msg00235 .htmlを
[Metzger1998] Metzger, P., "Re: what a new TCP header might look like", May 12, 1998. ftp://ftp.isi.edu/end2end/end2end-interest-1998.mail
[Metzger1998]メッツガー、P.、 "再：どのような新しいTCPヘッダは次のようになります"、5月12日、1998年ftp://ftp.isi.edu/end2end/end2end-interest-1998.mail
[Morris1985] Morris, R., "A Weakness in the 4.2BSD Unix TCP/IP Software", Technical Report CSTR-117, AT&T Bell Laboratories, February 1985. http://pdos.csail.mit.edu/~rtm/papers/117.pdf
[Morris1985]モリス、R.、 "4.2BSD UNIXのTCP / IPソフトウェアで弱さ"、技術報告書CSTR-117、AT＆Tベル研究所、2月1985 http://pdos.csail.mit.edu/~rtm/論文/ 117.pdf
[MSV2009] Metzger, P., Simpson, W., and P. Vixie, "Improving TCP Security With Robust Cookies", Usenix ;login:, December 2009. http://www.usenix.org/publications/login/ 2009-12/openpdfs/metzger.pdf
[MSV2009]メッツガー、P.、シンプソン、W.、およびP.いるVixie、 "堅牢なクッキーでTCPセキュリティの改善"、のUsenixは、:, 12月ログイン2009 http://www.usenix.org/publications/login/ 2009 -12 / openpdfs / metzger.pdf
[Phrack1998] route|daemon9, "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue 53, July 8, 1998. http://www.phrack.org/issues.html?issue=53&id=6
[Phrack1998]ルート| daemon9、 "T / TCPの脆弱性"、Phrack誌、8巻、号53、7月8日、1998年http://www.phrack.org/issues.html?issue=53&id=6
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1379, November 1992.
[RFC1379]ブレーデン、R.、 "取引のための拡張TCP - 概念"、RFC 1379、1992年11月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、R.、 "T / TCP - 取引機能仕様のためのTCP拡張機能"、RFC 1644、1994年7月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]カーン、P.とW.シンプソン、 "Photuris：セッション鍵管理プロトコル"、RFC 2522、1999年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]石、J.、スチュワート、R.、およびD.オーティス、 "ストリーム制御伝送プロトコル（SCTP）チェックサムの変更"、RFC 3309、2002年9月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]フェナー、B.、RFC 4727、2006年11月 "のIPv4、IPv6の、ICMPv4の、ICMPv6の、UDP、およびTCPヘッダには実験値"。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and Internet Architecture Board, "Internet Denial-of-Service Considerations", RFC 4732, November 2006.
[RFC4732]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびインターネットアーキテクチャ委員会、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年11月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]タッチ、J.、RFC 4953、2007年7月 "なりすまし攻撃に対するTCPを防衛"。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、RFC 4987、2007年8月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、周、H.、Eronen、P.、およびH. Tschofenig、 "サーバー側の状態なしのトランスポート層セキュリティ（TLS）セッション再開"、RFC 5077、2008年1月。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
[RFC5358]ダマ、J.およびF.ネベス、 "反射攻撃に再帰ネームサーバの使用を防止する"、BCP 140、RFC 5358、2008年10月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]をタッチし、J.、マンキン、A.、およびR. Bonica、 "TCP認証オプション"、RFC 5925、2010年6月。
[RFC6056] Larson, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]ラーソン、M.とF. Gont、BCP 156、RFC 6056、2011年1月 "トランスポート・プロトコルポートランダム化のための提言"。
[rfc1323bis] Borman, D., Braden, R., and V. Jacobson., "TCP Extensions for High Performance", Work in Progress, March 2009.
[rfc1323bis]ボーマン、D.、ブレーデン、R.、およびV.ヤコブソン。、 "ハイパフォーマンスのためのTCP拡張"、進歩、2009年3月での作業。
Author's Address
著者のアドレス
Questions about this document can be directed to:
この文書に関する質問をするように指示することができます。
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアムアレンシンプソン空想家コンピュータシステムズコンサルティングサービス1384フォンテーヌマディソンハイツ、ミシガン州48071
EMail: William.Allen.Simpson@Gmail.com
メールアドレス：William.Allen.Simpson@Gmail.com