[要約] RFC 6013は、TCP Cookie Transactions（TCPCT）プロトコルに関する仕様です。TCPCTは、TCP接続の確立と維持を改善するために設計されており、クライアントとサーバー間のCookieベースのトランザクションを提供します。このRFCは、TCPCTの目的と仕組みを詳細に説明しています。
Independent Submission W. Simpson
Request for Comments: 6013 DayDreamer
Category: Experimental January 2011
ISSN: 2070-1721
TCP Cookie Transactions (TCPCT)
TCPクッキートランザクション（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 Cookieトランザクション（TCPCT）接続のスプーフィングを阻止し、リソースの使い果たしを防ぎ、最初の握手中にレスポンダー（サーバー）状態を排除します。イニシエーター（クライアント）は、接続間の必要な遅延を保証する唯一の責任を負います。Cookie Exchangeは、増幅および反射拒否のサービス攻撃を阻害することに限定されているデータを伝達する場合があります。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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 Cookie Transactions（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.
接続確立中、Cookie（NonCe）Exchangeは、Responder（サーバー）状態の排除を交渉します。これらのCookieは、後に接続の早期閉鎖を阻害し、接続が終了した後に状態の保持を減らすために使用されます。
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.
Cookieペアは、最大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.
また、実装は、最初のCookie交換中に限られた量のトランザクションデータをオプションで交換し、ネットワークの遅延とホストタスクコンテキストの切り替えを削減する場合があります。
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].
これらのアイデアの多くは、以前に何らかの形で提案されています（履歴と謝辞セクションを参照）。この仕様は、これらの改善をコヒーレント全体に統合します。さらなる動機と理論的根拠が[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」、「optional」、「optional」、「推奨」、「必須」、「必要」、「必要はない」というキーワードは、[RFC2119]に記載されているように解釈されるべきではありません。
byte An 8-bit quantity; also known as "octet" in standardese.
バイト8ビット数量。Standardeseの「Octet」としても知られています。
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.
Cookieオプションは、オプションの<syn>データが許容できることも示しています。このデータは、いずれかの当事者によって無視される場合があります。
A Responder that understands the Cookie option remains stateless.
Cookieオプションを理解しているレスポンダーは、ステートレスのままです。
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>に存在する他のオプションは、<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.
レスポンダーは最初のデータをCookie-Pairに返すことに注意してくださいが、その後のデータセグメントにはタイムスタンプのみが必要です。
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.
タイムスタンプとクッキーペアを検証すると、レスポンダーは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）> - >フルオプションタイムスタンプCookie-Pair [sack（response）] data < - <ack>フルオプションタイムスタンプCookie-Pairデータ（作成された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>タイムスタンプCookie-pair <fin、ack（fin）> - > Timestams cookie-pair < - <ack（fin）> Timestams cookie-pair（tcb State removed）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実装は、実装しないTCPオプションをエラーなしで無視する必要があります（[RFC1122]セクション4.2.2.5）。輸送プロトコル[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.
それらをすべて支援するために1つの種類、それらを見つけるために1つの種類、それらすべてを保持し、ヘッダーに結合するために1つの種類。
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.
Cookie Exchangeは、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.何よりもまず、Cookie Exchangeは、洪水攻撃に対する脆弱なサーバーの運用セキュリティを改善します。Cookie Exchangeは、Responder（サーバー）が初期状態を破棄することを示しています。他のすべてのセマンティクスは下位です。
B. Together with Sequence and Timestamp values, Cookie values protect against insertion and reflection attacks.
B.シーケンスとタイムスタンプの値とともに、Cookie値は挿入攻撃と反射攻撃から保護します。
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値は、アプリケーションセキュリティプロトコルのインデックスまたはNonCEとして使用できます。この施設は、この仕様の範囲を超えています。
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）>は、アプリケーションデータを運ぶ場合があります。この機能は完全にオプションであり、データはミドルウェアを介して正常に渡すことは保証されていません。また、当事者は、アプリケーションプログラムインターフェイス（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. Cookieのサイズは、標準のTCPヘッダースペースの他のほとんどのオプションを排除します。Cookie Exchangeは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. Cookie Exchangeおよび結果として生じるTCPヘッダー拡張により、大きな帯域幅遅延製品を備えたパスのより大きな64ビット（または128ビット）タイムスタンプの交渉が許可されます。
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. Cookie Exchangeは、加速された近接を使用するという合意を示しています。
K. The cookie exchange indicates agreement that only the Initiator (client) handles TIME-WAIT state.
K. Cookie Exchangeは、イニシエーター（クライアント）のみがタイムウェイト状態を処理するという合意を示します。
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.
Cookieオプションが正常に交換されると、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.
応答者は最初のTCP <Syn> Exchangeの後に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>ベアリングセグメント（<syn、ack（syn）>を含む）でのみ表示されていました。存在する場合、MSSはInitiator <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>と同じように扱われます。Responderは、タイムスタンプとCookie-Pairオプションの両方を含む後続の<Ack>セグメントを使用していることを認めています（<syn、ack（syn）>処理）。
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]。DONTフラグメント（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.
Cookie、Cookie-Less、またはCookie-Pairオプションのいずれかで許可されているインスタンスは1つだけです。重複または相互に排他的なオプションを備えたセグメントは、静かに廃棄する必要があります。
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（バイト）;オプションフィールドの残りのスペースによって制限されます。番号は偶数でなければなりません。Cookieは16ビットの倍数です。
Cookie 8 to 16 bytes (Length - 2): an unpredictable value.
Cookie 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.
レスポンダークッキーは、イニシエータークッキーと同じサイズでなければなりません。Cookieペアは32ビットの倍数です。
Although the diagram shows a cookie aligned on 32-bit boundaries, that is not required.
図は、32ビットの境界に並べられたCookieを示していますが、それは必要ありません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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（バイト）。番号は偶数でなければなりません。Cookieペアは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)>.
Responder-Cookie 8〜16バイト、<syn、ack（syn）>から。
The Cookie-Pair standard option only appears after the Timestamps extended option (below).
Cookie-Pair標準オプションは、タイムスタンプが拡張オプション（以下）の後にのみ表示されます。
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ビットであるため、最小Cookieペアは128ビット（64ビットに続いて64ビット）、最大は256ビット（128ビットに続いて128ビット）です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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（バイト）。これにより、オプションが他のCookieオプションと区別されます。
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.
Cookieは添付されていませんが、これは、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.
1バイトを拡張：範囲9〜255。標準のTCPヘッダーに続くデータオフセット（32ビット語）。注この値には、（s）izeで示されるタイムスタンプペアを含める必要があります。
(R)eserved 5 bits: default zero. Reserved for future use.
（r）5ビットのeServed：デフォルトゼロ。将来の使用のために予約されています。
(S)ize 3 bits:
（s）3ビット：
1. 32-bit timestamps.
1. 32ビットタイムスタンプ。
2. 64-bit timestamps.
2. 64ビットタイムスタンプ。
4. 128-bit timestamps.
4. 128ビットタイムスタンプ。
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つの1つの（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ビット）タイムスタンプ標準オプションまたはこのタイムスタンプ拡張オプションのいずれかについては、1つのインスタンスのみが許可されています。重複または相互に排他的なオプションを備えたセグメントは、静かに廃棄する必要があります。
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:
パーティーがCookieを生成する手法は、実装に依存します。選択した方法は、いくつかの基本的な要件を満たす必要があります。
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. Cookieは特定の関係者に依存する必要があります。これにより、攻撃者が実際のIPアドレスとTCPポートを使用してCookieを取得し、ランダムに選択した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を生成することは不可能であってはなりません。これは、発行エンティティがCookieの生成とその後の検証におけるローカルシークレット情報を使用することを意味します。特定のCookieからこの秘密の情報を推測することは不可能であってはなりません。
3. The cookie generation and verification methods MUST be fast to thwart attacks intended to sabotage CPU resources.
3. CPUリソースを妨害することを目的とした攻撃を阻止するために、Cookieの生成方法と検証方法は速くなければなりません。
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.
Cookieに影響を与えるイニシエーターの秘密値は、新しい交換ごとに変更され、その後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.
別の方法は、秘密の値の代わりにCookieをキャッシュすることです。着信クッキーは、再生の計算コストなしで直接比較できます。
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.
Cookieは、秘密の値、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).
Cookieに影響を与えるレスポンダーの秘密の値は、多くの異なるイニシエーターで同じままです。ただし、この秘密は、Cookieの使用時間を制限するために定期的に変更する必要があります（通常は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.
Responder-Cookie計算には、独自の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.
Cookieは、秘密の値、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.
Cookieは、最初のTCP <Syn> Exchange中に状態を保存しないように、イニシエーターごとにキャッシュされていません。TCP <ACK（syn）>を受信すると、レスポンダーは検証のためにCookieを再生します。
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 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.
レスポンダーCookieは、将来の検証のために表示されるTCPシーケンスと確認番号に依存します。シーケンス番号は、認識される<syn>の初期シーケンス番号（ISN）と1つの1つの（1）になります。確認番号は、現在認めている<syn>の初期シーケンス番号（ISN）と1つの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ビットのみが含まれています。イニシエーターのタイムスタンプフィールド値は、交換中に増加する場合があります。含めてはいけません。
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.
秘密の値は、可変長さデータの代替を使用して、事前に計算された攻撃からよりよく保護するために2回含まれています。この手法を使用した例のいくつかは、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.
レスポンダーは、Cookieの（固定またはランダムに選択された）ビットを指定して、変更された各秘密値を区別する必要があります。ビットは（固定またはランダムに選択された）定数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.
レスポンダーCookieがイニシエーターCookieと同一である場合、レスポンダーは、反射攻撃としての偶発的な外観を防ぐために、Cookieの1ビット以上を変更する必要があります。
Each Responder maintains up to two secret values concurrently for efficient secret rollover. Each secret value has 4 states:
各レスポンダーは、効率的な秘密のロールオーバーのために、最大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).
生成すると、新しいレスポンダークーキーが生成されますが、主要な検証にはまだ使用されていません。これは短期的な状態であり、通常は1回の往復時間（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.
新しい生成秘密によって検証できる最初の障害まで、検証に使用された退職。当時、このCookieの状態は二次に変更され、生成されるCookieの状態はプライマリに変更されます。これは短期的な状態であり、通常は1つの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.
一次検証障害後の二次検証に使用される二次。この状態は、最大セグメント寿命（2MSL）の2倍未満です。その後、秘密は破棄されます。
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.
初期化後の最初の秘密は、一次状態で始まります。システムは、前の最初の秘密の間にシャットダウンし、迅速に再起動した可能性があります。したがって、最初の秘密は部分的に時間依存している必要があり、通常は最初の秘密を延ばすために時間を追加することにより、以前の最初の秘密とは異なることを確認します。最初の秘密ではないものは時間を含めるべきではありません。
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タイムウェイトの要件はありません。また、忙しいサービスに対する需要が高まっている可能性があります。また、以前のCookie Exchangeを完了しようとする優れたデータグラムがある場合があります。最近のエントロピーが含まれていないため、最初の秘密は最も弱いと思われます。
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.
実装は、チェックサム、Cookie、タイムスタンプ、パケットの到着タイミングから追加のエントロピーを継続的に収集する必要があります。
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.
Cookie Exchangeは、タイムスタンプクロックの頻度によってのみ制限されているときにいつでも開始できます。
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値を生成し、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>.
最初の交換中、イニシエーターは再送信の責任を単独で担当します。Cookieとシーケンスは変更されていませんが、各再送信は別のオリジナル<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>をCookieオプションで受信すると、Responderは別の接続を開始するのに十分なリソースがあるかどうかを決定します。
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.
レスポンダーは、予測不可能なCookie値を生成し、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.
応答者は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）>をCookieオプションで受信すると、イニシエーターはCookie、タイムスタンプ、および対応する確認番号を検証します。既存の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>オプションは、この最初の<ACK（syn）>で常に再送信され、レスポンダーがCookieを検証して状態を確立できるようにします。
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.
イニシエーターCookieと同一のレスポンダーCookieを破棄する必要があります。これは通常、中央（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.
Cookie-Pairオプションを使用して<ACK（syn）>を受信すると、レスポンダーはCookie、タイムスタンプ、および対応する確認番号を検証し、接続の状態を確立します。既存の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を使用すると、2つの関係者が接続を同時に開始できます。両当事者は、介入<syn、ack（syn）>（[rfc793]セクション3.4および図8を参照）なしでオリジナル<syn>を送信および受け取ります。各パーティは、クッキーも発行した<ソースアドレス、ソースポート、宛先アドレス、宛先ポート>接続用のCookieを受け取ります。
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>を静かに破棄します。レスポンダーはCookieオプションを修正し、<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>で閉じることができます。これは、最終的なデータセグメントで送信する必要があります。
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.)
閉鎖後にレスポンダーがTCB状態を保持していないため、オプション交換の成功は、イニシエーターがタイムウェイト状態を処理する責任を負います。（以前の提案と根拠については、[FTY1999]セクション3を参照してください。）
A new Cookie exchange MAY be initiated at any time. This facilitates persistent connections through intervening network equipment.
新しいCookie Exchangeはいつでも開始される場合があります。これにより、介在するネットワーク機器を介して永続的な接続が容易になります。
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.
Responder <FIN、ACK（FIN）>（およびタイムスタンプの検証とCookie-PAIRオプションの検証）を受信すると、イニシエーターは、追加データが保留中でない限り、最終<ACK（FIN）>を送信します。イニシエーターはタイムウェイト状態に入ります。
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）>（およびタイムスタンプとCookie-PAIRオプションの検証）を受信すると、Responderは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.
新しいCookie Exchangeを促すより多くのデータが到着すると、イニシエーターは最終<ACK（FIN）>を送信してはなりません。既存のtsoffsetをインクリメントする必要があります。Tsoffsetは、将来のタイムウェイト状態の終わりに（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.
Responder <fin>（およびタイムスタンプとCookie-Pairオプションの検証）を受け取ると、イニシエーターは、追加のデータが保留中でない限り、その<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）>（およびタイムスタンプの検証とCookie-PAIRオプションの検証）を受信すると、Responderは最終<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.
ResponderのFinal <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.
Responderの最終<ACK（FIN）>（およびタイムスタンプとCookie-PAIRオプションの検証）を受信すると、イニシエーターはタイムウェイト状態に入ります。
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.
新しいCookie Exchangeを促すより多くのデータが到着したとき、イニシエーターは<FIN、ACK（FIN）>、および/または残りの時間との間隔を待ってはなりません。既存のtsoffsetをインクリメントする必要があります。Tsoffsetは、将来のタイムウェイト状態の終わりに（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.
アプリケーションがiDempotentトランザクション（一貫した結果の見出しを返すクエリなど）が可能な場合、アプリケーションは各ポートまたは接続に対して適切な制限を個別に設定します。アプリケーションは、再送信がデータの重複を引き起こさないことを保証する責任があります。
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>にはデータが含まれていません。アプリケーションはTCP_SYN_DATA_LIMITを設定して、<Syn>をデータとともに送信できることを示します。
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>.
最初の交換中、イニシエーターは再送信の責任を単独で担当します。Cookieとシーケンスは変更されていませんが、各再送信は別のオリジナル<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.
Initiator <syn、fin> Cookieオプションを使用して、テスト環境ではセグメントデータは許可されていません。この組み合わせは静かに廃棄する必要があります。
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.
Cookieオプションとセグメントデータの両方を使用したinitiator <syn、fin>は、T/TCP [RFC1644]に似ています。ただし、Responder <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.
デフォルトでは、Responder <syn、ack（syn）>にはデータが含まれていません。アプリケーションはTCP_SYN_ACK_DATA_LIMITを設定して、<syn、ack（syn）>をデータとともに送信できることを示します。
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>をCookieオプションで受信すると、レスポンダーは存在するデータを処理できます。初期データが受け入れられない場合、確認番号は、<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>を設定しないでください。アプリケーションはプッシュを使用してそのデータを送信する準備ができていることを示す場合がありますが、プッシュは<fin>データセグメントに暗示されています（[RFC793]セクション3.7、41ページを参照）。
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.
応答者はTCB状態を保持していないため、再送信タイマーは利用できません。イニシエーターの再送信の到着は、オリジナルの<syn>送信のようです。処理に違いはありません。
Implementation Notes:
実装メモ：
The Responder Cookie depends on the TCP Sequence and Acknowledgment Numbers after processing <SYN>. Therefore, neither will include data.
レスポンダーCookieは、<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）>をCookieオプションで受信すると、イニシエーターは存在するデータを処理できます。この場合、内部rcv.nxtを進めて、一時的なセマンティクスを提供します。
If the segment data is the entire response (there is no further data expected), the Initiator enters TIME-WAIT state.
セグメントデータが応答全体である場合（これ以上のデータは予想されていません）、イニシエーターはタイムウェイト状態に入ります。
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つの（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.
Selective Auncoundment（sack）オプション[RFC2018]が正常にネゴシエートされた場合、拡張ヘッダーのCookie-Pairに続いて応答データを確認する短いサックが送信される場合があります。
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>を待たずに2番目のセグメントを送信できます。
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>.
新しいCookie Exchangeを促すより多くのデータが到着すると、以前のタイムスタンプを増やす必要はありません。TCB状態はレスポンダーで保存されていません。代わりに、保存されたrcv.nxtを使用し、（実際のまたは暗示）<fin>に1つを使用します。
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.
Initiator <ACK（Syn）、Fin> Cookie-Pairオプションを使用して、セグメントデータは不要です。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.
Cookie-Pairオプション（およびタイムスタンプとCookie-Pairオプションの検証）を使用して<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シーケンスと確認番号は進んでいないため、レスポンダーは同じ着信データを処理し、同じ応答を送信します。
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.
選択的承認（SACK）オプション[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>を待たずに2番目のセグメントを送信できます。
When a TCB with matching Addresses and Ports is found, but the Cookie-Pair fails to verify, the datagram MUST be silently discarded.
一致するアドレスとポートを備えたTCBが見つかったが、Cookie-Pairが確認できない場合、データグラムは静かに破棄する必要があります。
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が見つからない場合、A <rst>は通常どおり送信されます。タイムスタンプオプションはコピーする必要があります[RFC1323]。Cookie-Pairオプションもコピーする必要があります。Cookieオプション（またはCookie-Lessオプション）をコピーしないでください。
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>は常にアドバイザリーとして扱われます。一致するCookie-Pairオプションのない<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.
成功したCookie（またはCookie-Less）オプション交換シグナル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.
Cookie Exchangeの間、<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>のCookieオプションで使用を妨げます。システムのデフォルトに関係なく、Cookieオプションを送信する必要はなく、受領時に無視する必要があります。代わりに、Cookie-Less Extensionオプションは、この仕様の他の機能が利用可能であることを示しています。
(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>のCookieオプションで使用を妨げます。システムのデフォルトに関係なく、Cookieオプションを送信する必要はなく、受領時に無視する必要があります。代わりに、Cookie-Less Extensionオプションは、この仕様の他の機能が利用可能であることを示しています。
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.
現在バージョン1（1994年12月から1995年3月）と呼ばれるPhyuris [RFC2522]の最初の仕様[KS1995]は、設計要件の短いリストとPhil Karnによる簡単な実験コードに基づいています。「Cookie」は、偽のIPソースまたはUDPポートを使用して送信された単純な洪水攻撃に対して守られています。
During 1995, the Photuris efficient secret rollover and many other extensions were specified. Multiple interoperable implementations were produced.
1995年、Photuris Efficive Secret Rolloverおよび他の多くの拡張機能が指定されました。複数の相互運用可能な実装が作成されました。
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）攻撃は、人気のある（そして不人気な）サーバーとサイトを壊滅させました。Phil Karnは、非詰めのクッキーをTCPに適応させることに非公式に言及しました。ペリー・メッツガーは、「TCP」の取り組み[Metzger1996]の一部としてKarnのCookieを追加することを提案しました。
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年後半、ダニエルJ.バーンスタインは、TCP syn初期シーケンス番号（ISN）に埋め込まれた「Syn Cookies」を実装しました。このテクニックは、リモートパーティーの協力を必要とせず、一方的に展開できるため、非常に賢いものでした。ただし、Syn Cookieは緊急時にのみ使用できます。それらはほとんどのTCPオプションと互換性がありません。シーケンス番号にスペースが不十分なため、Cookieは暗号学的に安全であるとは見なされません。したがって、メカニズムはシステムが攻撃を受けているまで非アクティブなままであるため、動作中は十分にテストされません。Syn Cookieは最近まで公開されていませんでした[RFC4987]。
In 1998, Perry Metzger proposed adding Karn's cookies as part of a "TCPng" discussion [Metzger1998].
1998年、ペリーメッツガーは、「TCPNG」ディスカッション[Metzger1998]の一部としてKarnのCookieを追加することを提案しました。
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年、Faber、Touch、およびYue [FTY1999]は、時間待ち国家を維持する当事者を交渉するオプションを使用して提案しました。これにより、接続を閉じた後、サーバーが状態を完全に排除できます。
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年、Stream Control Transmission Protocol（SCTP）[RFC2960]は、光に基づいていると主張する不十分な部分的なCookieメカニズムで公開されました。不十分なチェックサム（2002年に優雅な移行なしで[RFC3309]に置き換えられました）を特徴とし、その後の改訂[RFC4960]を受けました。
In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was published with a mechanism analogous to SYN cookies.
2006年、Datagramの混雑制御プロトコル（DCCP）[RFC4340]は、Syn Cookieに類似したメカニズムで公開されました。
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].
Andre Broidoは、[RFC5077]チケットの代わりに、輸送層セキュリティ（TLS）セッション識別子のCookieを利用して非公式に説明しました。迅速な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.
Wesley M. EddyとAdam Langleyは、以前に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.
Adam Langleyは以前、別のオプション[Langley2008]を提案していました。彼（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.
Joe Touchは、（できれば仮説的な）障害モードを仮定しました：ミドルウェアによって再注文されたオプション。これにより、仕様の変化が生じ、オプションの相互作用と処理がかなり複雑になります。彼の有益なコメントは高く評価されました。
Many thanks to Fernando Gont for suggestions, and Rick Jones for performance testing.
提案をしてくれたFernando Gontと、パフォーマンステストのRick Jonesに感謝します。
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>でCookieオプションを送信します。
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]デフォルト：off。定義されている場合、32ビット、64ビット、または128ビットのタイムスタンプ拡張を指定できます。
TCPCT_IN_ALWAYS Default: off. Silently discard any incoming <SYN> that is missing the Cookie option.
tcpct_in_alwaysデフォルト：off。Cookieオプションが欠落している受信<syn>を静かに破棄します。
TCPCT_OUT_NEVER Default: off. Refuse to send (override) the Cookie option.
tcpct_out_neverデフォルト：off。Cookieオプションの送信（オーバーライド）を拒否します。
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.
Cookie Exchangeは、別の値を代用するために競争することができる侵入者や、値を変更および/または交換できるインターセプターから保護しません。これらの攻撃は、受動的な真空クリーナー監視よりもかなり困難です。
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）>は、レスポンダーCookieを置き換えることに注意してください。スプーフィングに対する保護は、シーケンスとタイムスタンプに完全に依存しているため、最初の交換は最も脆弱です。この交換戦略により、正しいペアを通過させることができますが、他のペアは後でレスポンダーの検証を介してフィルタリングされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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ビット）Cookieは、最大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.
Cookieは同じサイズであり、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.
Cookieオプションに従うなど、usertimeout（uto）オプションは、代わりに他の場所に表示できます。一部のミドルボックスはオプションの順序に敏感であるため、UTOはMSSの前ではTSとCookieの間で表示されないでください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
袋はサックックを意味します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
レスポンダーは小さなタイムスタンプ拡張オプションを返す場合がありますが、より大きな64ビット（または128ビット）タイムスタンプ拡張オプションを認識する必要があります。
Normative References
引用文献
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のための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] Mathis、M.、Mahdavi、J.、Floyd、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「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] Reynolds、J.、ed。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5452] Hubert、A。およびR. Van Mook、「Forged Answersに対してDNSをより回復力のあるものにするための対策」、RFC 5452、2009年1月。
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, March 2009.
[RFC5482] Eggert、L。およびF. Gont、「TCPユーザータイムアウトオプション」、RFC 5482、2009年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「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] Eddy、W。and A. Langley、「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] Faber、T.、Touch、J。、およびW. Yue、「TCPの時間待機状態と忙しいサーバーへの影響」、IEEE Infocom 99、pp。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
[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] Kohno、T.、Broido、A。、およびK. C. Claffy、「リモート物理デバイスフィンガープリント」、セキュリティとプライバシーに関するIEEEシンポジウム、2005年5月。http：//www.caida.org/ outreach/papers/2005/フィンガープリント/ kohnobroidoclaffy05-devicefingerprinting.pdf
[KS1995] Karn, P. and W. Simpson, "The Photuris Session Key Management Protocol", March 1995.
[KS1995] Karn、P。およびW. Simpson、「Photuris Session Key Management Protocol」、1995年3月。
Published as: "Photuris: Design Criteria", Proceedings of Sixth Annual Workshop on Selected Areas in Cryptography, LNCS 1758, Springer-Verlag. August 1999.
「Phyuris：Design Criteria」、Cryptography、LNCS 1758、Springer-Verlagの第6回年次ワークショップの議事録。1999年8月。
[Langley2008] Langley, A., "Faster application handshakes with SYN/ACK payloads", Work in Progress, August 2008.
[Langley2008] Langley、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] Medina、A.、Allman、M。、およびS. Floyd、「輸送プロトコルとミドルボックス間の相互作用の測定」、Proceedings 4th ACM Sigcomm/Usenix Conference on Internet Measurement、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] Metzger、P。、「Re：Syn Floods（was：history recody repeat oter？）」、1996年9月9日。.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] Metzger、P。、「Re：新しいTCPヘッダーはどのように見えるかもしれない」、1998年5月12日。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] Morris、R。、「4.2BSD UNIX TCP/IPソフトウェアの弱点」、テクニカルレポートCSTR-117、AT＆T Bell Laboratories、1985年2月。http：//pdos.csail.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] Metzger、P.、Simpson、W.、およびP. Vixie、「堅牢なCookieによるTCPセキュリティの改善」、Usenix; Login：、2009年12月。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 Magazine、Volume 8、Issue 53、1998年7月8日。http：//www.phrack.org/issues.html?issue=53&id=6
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1379, November 1992.
[RFC1379] Braden、R。、「トランザクションのTCPの拡張 - 概念」、RFC 1379、1992年11月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644] Braden、R。、「T/TCP -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] Karn、P。およびW. Simpson、「Phyuris：Session-Key Management Protocol」、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.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、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.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309] Stone、J.、Stewart、R。、およびD. Otis、「Stream Control Transmission Protocol（SCTP）Checkum Change」、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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[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] Baker、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] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and Internet Architecture Board, "Internet Denial-of-Service Considerations", RFC 4732, November 2006.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、ed。、およびInternet Architecture Board、「Internet-of-Serial-of-Serial-of-Serial-of-Serial-of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-Serial Of-4732、2006年11月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953] Touch、J。、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月。
[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.、Zhou、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] Damas、J。およびF. Neves、「リフレクター攻撃での再帰的な名前の使用の防止」、BCP 140、RFC 5358、2008年10月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、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] Larson、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] Borman、D.、Braden、R。、およびV. Jacobson。、「高性能のための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