[要約] RFC 5482は、TCPユーザータイムアウトオプションに関する仕様を定めたものであり、TCP接続のタイムアウトを制御するための機能を提供します。このRFCの目的は、ネットワークの遅延や障害によるTCP接続のタイムアウトを適切に処理するための標準化を促進することです。
Network Working Group L. Eggert
Request for Comments: 5482 Nokia
Category: Standards Track F. Gont
UTN/FRH
March 2009
TCP User Timeout Option
TCPユーザータイムアウトオプション
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.
TCPユーザーのタイムアウトは、接続が強制的に閉じられる前に、送信されたデータが未充填のままである可能性がある期間を制御します。これは、ローカル、接続ごとのパラメーターです。このドキュメントは、TCP接続の一端が現在のユーザータイムアウト値を宣伝できるようにする新しいTCPオプション（TCPユーザータイムアウトオプション）を指定します。この情報は、TCP接続のもう一方の端にアドバイスを提供し、それに応じてユーザーのタイムアウトを適応させます。TCP接続の両端でユーザーのタイムアウトを増やすことで、エンドツーエンドの接続なしで長期間に耐えることができます。ユーザーのタイムアウトを減らすことで、忙しいサーバーは、接続なしで短時間のみ接続状態を維持することをクライアントに明示的に通知することができます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Operation .......................................................4
3.1. Changing the Local User Timeout ............................5
3.2. UTO Option Reliability .....................................8
3.3. Option Format ..............................................8
3.4. Reserved Option Values .....................................9
4. Interoperability Issues .........................................9
4.1. Middleboxes ................................................9
4.2. TCP Keep-Alives ...........................................10
5. Programming and Manageability Considerations ...................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
The Transmission Control Protocol (TCP) specification [RFC0793] defines a local, per-connection "user timeout" parameter that specifies the maximum amount of time that transmitted data may remain unacknowledged before TCP will forcefully close the corresponding connection. Applications can set and change this parameter with OPEN and SEND calls. If an end-to-end connectivity disruption lasts longer than the user timeout, a sender will receive no acknowledgments for any transmission attempt, including keep-alives, and it will close the TCP connection when the user timeout occurs.
トランスミッションコントロールプロトコル（TCP）仕様[RFC0793]は、TCPが対応する接続を強制的に閉じる前に送信されたデータが未把握のままである可能性がある最大時間を指定するローカル、接続ごとの「ユーザータイムアウト」パラメーターを定義します。アプリケーションは、このパラメーターをオープンコールと送信で設定および変更できます。エンドツーエンドの接続の破壊がユーザーのタイムアウトよりも長く続く場合、送信者はキープアリブを含む送信試行の謝辞を受け取りません。また、ユーザーのタイムアウトが発生したときにTCP接続を閉じます。
This document specifies a new TCP option -- the TCP User Timeout Option (UTO) -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the connection to adapt its user timeout accordingly. That is, TCP remains free to disregard the advice provided by the UTO option if local policies suggest it to be appropriate.
このドキュメントは、TCP接続の一端が現在のユーザータイムアウト値を宣伝できるようにする新しいTCPオプション（TCPユーザータイムアウトオプション（UTO））を指定します。この情報は、それに応じてユーザーのタイムアウトを適応させるために、接続のもう一方の端へのアドバイスを提供します。つまり、TCPは、現地のポリシーが適切であることが示唆されている場合、UTOオプションによって提供されるアドバイスを自由に無視することができます。
Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.
TCP接続の両端でユーザーのタイムアウトを増やすことで、エンドツーエンドの接続なしで長期間に耐えることができます。ユーザーのタイムアウトを減らすことで、忙しいサーバーは、接続なしで短時間のみ接続状態を維持することをクライアントに明示的に通知することができます。
In the absence of an application-specified user timeout, the TCP specification [RFC0793] defines a default user timeout of 5 minutes. The Host Requirements RFC [RFC1122] refines this definition by introducing two thresholds, R1 and R2 (R2 > R1), that control the number of retransmission attempts for a single segment. It suggests that TCP should notify applications when R1 is reached for a segment, and close the connection when R2 is reached. [RFC1122] also defines the recommended values for R1 (3 retransmissions) and R2 (100 seconds), noting that R2 for SYN segments should be at least 3 minutes. Instead of a single user timeout, some TCP implementations offer finer-grained policies. For example, Solaris supports different timeouts depending on whether a TCP connection is in the SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS].
アプリケーション指定のユーザータイムアウトがない場合、TCP仕様[RFC0793]は、デフォルトのユーザータイムアウトの5分を定義します。ホスト要件RFC [RFC1122]は、単一セグメントの再送信試行の数を制御する2つのしきい値、R1とR2（R2> R1）を導入することにより、この定義を改良します。これは、TCPがセグメントのR1に到達したときにアプリケーションを通知し、R2に到達したときに接続を閉じる必要があることを示唆しています。[RFC1122]は、R1（3回の再送信）とR2（100秒）の推奨値も定義し、SynセグメントのR2は少なくとも3分であることに注意してください。単一のユーザーのタイムアウトの代わりに、一部のTCP実装はより細かい粒度のポリシーを提供します。たとえば、Solarisは、TCP接続がSyn-Sent、Syn-Received、または確立された状態[Solaris]にあるかどうかに応じて、異なるタイムアウトをサポートしています。
Although some TCP implementations allow applications to set their local user timeout, TCP has no in-protocol mechanism to signal changes to the local user timeout to the other end of a connection. This causes local changes to be ineffective in allowing a connection to survive extended periods without connectivity, because the other end will still close the connection after its user timeout expires.
一部のTCP実装により、アプリケーションはローカルユーザーのタイムアウトを設定できますが、TCPには、ローカルユーザーのタイムアウトの変更を接続の反対側に通知するプロトコル内メカニズムがありません。これにより、接続が接続せずに長期間に耐えることができるようにするには、局所的な変更が効果的ではありません。これは、ユーザーのタイムアウトが期限切れになった後ももう一方の端が接続を閉じるためです。
The ability to inform the other end of a connection about the local user timeout can improve TCP operation in scenarios that are currently not well supported. One example of such a scenario is mobile hosts that change network attachment points. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423], or transport-layer mobility mechanisms [TCP_MOB], are only intermittently connected to the Internet. In between connected periods, mobile hosts may experience periods without end-to-end connectivity. Other factors that can cause transient connectivity disruptions are high levels of congestion or link or routing failures inside the network. In these scenarios, a host may not know exactly when or for how long connectivity disruptions will occur, but it might be able to determine an increased likelihood for such events based on past mobility patterns and thus benefit from using longer user timeouts. In other scenarios, the time and duration of a connectivity disruption may even be predictable. For example, a node in space might experience connectivity disruptions due to line-of-sight blocking by planetary bodies. The timing of these events may be computable from orbital mechanics.
ローカルユーザーのタイムアウトに関する接続のもう一方の端に通知する機能は、現在十分にサポートされていないシナリオでTCP操作を改善できます。このようなシナリオの1つの例は、ネットワーク添付のポイントを変更するモバイルホストです。このようなホストは、おそらくモバイルIP [RFC3344]、HIP [RFC4423]、または輸送層のモビリティメカニズム[TCP_MOB]を使用して、断続的にインターネットに接続されています。接続された期間の間に、モバイルホストはエンドツーエンドの接続なしで期間を経験する場合があります。一時的な接続の混乱を引き起こす可能性のある他の要因は、ネットワーク内の輻輳またはリンク、またはルーティングの障害の高レベルです。これらのシナリオでは、ホストは接続の破壊がいつまたはどれくらいの期間発生するかを正確に知らない場合がありますが、過去のモビリティパターンに基づいてそのようなイベントの可能性の増加を判断することができ、したがって、より長いユーザーのタイムアウトを使用することで利益を得ることができます。他のシナリオでは、接続性の破壊の期間と期間は予測可能な場合さえあります。たとえば、宇宙のノードは、惑星体による視線の遮断のために接続性の混乱を経験する可能性があります。これらのイベントのタイミングは、軌道力学から計算可能です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Use of the TCP User Timeout Option can be either enabled on a per-connection basis, e.g., through an API option, or controlled by a system-wide setting. TCP maintains four per-connection state variables to control the operation of the UTO option, three of which (ADV_UTO, ENABLED, and CHANGEABLE) are new:
TCPユーザータイムアウトオプションの使用は、接続ごとのベースで、たとえばAPIオプションを介して有効にするか、システム全体の設定で制御できます。TCPは、4つの接続ごとの状態変数を維持してUTOオプションの動作を制御します。
USER_TIMEOUT TCP's USER TIMEOUT parameter, as specified in [RFC0793].
[RFC0793]で指定されているように、user_timeout TCPのユーザータイムアウトパラメーター。
ADV_UTO UTO option advertised to the remote TCP peer. This is an application-specified value, and may be specified on a system-wide basis. If unspecified, it defaults to the default system-wide USER TIMEOUT.
ADV_UTO UTOオプションは、リモートTCPピアに宣伝されています。これはアプリケーションに指定された値であり、システム全体で指定される場合があります。不特定の場合、デフォルトはデフォルトのシステム全体のユーザータイムアウトになります。
ENABLED (Boolean) Flag that controls whether the UTO option is enabled for a connection. This flag applies to both sending and receiving. Defaults to false.
UTOオプションが接続に有効になっているかどうかを制御する（Boolean）フラグを有効にします。このフラグは、送信と受信の両方に適用されます。デフォルトはfalseになります。
CHANGEABLE (Boolean) Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT parameter) may be changed based on an UTO option received from the other end of the connection. Defaults to true and becomes false when an application explicitly sets USER_TIMEOUT.
接続のもう一方の端から受信したUTOオプションに基づいて、user_timeout（TCPのユーザータイムアウトパラメーター）を制御する変更可能な（ブール）フラグ。デフォルトはtrueになり、アプリケーションがuser_timeoutを明示的に設定するとfalseになります。
Note that an exchange of UTO options between both ends of a connection is not a binding negotiation. Transmission of a UTO option is a suggestion that the other end consider adapting its user timeout. This adaptation only happens if the other end of the connection has explicitly allowed it (both ENABLED and CHANGEABLE are true).
接続の両端間のUTOオプションの交換は、拘束力のある交渉ではないことに注意してください。UTOオプションの送信は、反対側がユーザーのタイムアウトの適応を検討することを提案します。この適応は、接続のもう一方の端が明示的に許可されている場合にのみ発生します（有効化され、変更可能な両方が真実です）。
Before opening a connection, an application that wishes to use the UTO option enables its use by setting ENABLED to true. It may choose an appropriate local UTO by explicitly setting ADV_UTO; otherwise, UTO is set to the default USER TIMEOUT value. Finally, the application should determine whether it will allow the local USER TIMEOUT to change based on received UTO options from the other end of a connection. The default is to allow this for connections that do not have specific user timeout concerns. If an application explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false in order to prevent UTO options (from the other end) from overriding local application requests. Alternatively, applications can set or clear CHANGEABLE directly through API calls.
接続を開く前に、UTOオプションを使用したいアプリケーションを使用すると、有効に設定することにより、その使用が可能になります。ADV_UTOを明示的に設定することにより、適切なローカルUTOを選択できます。それ以外の場合、UTOはデフォルトのユーザータイムアウト値に設定されます。最後に、アプリケーションは、接続のもう一方の端から受信したUTOオプションに基づいてローカルユーザーのタイムアウトが変更できるかどうかを判断する必要があります。デフォルトは、特定のユーザータイムアウトの懸念がない接続にこれを許可することです。アプリケーションがuser_timeoutを明示的に設定した場合、UTOオプション（反対側から）がローカルアプリケーションリクエストをオーバーライドするのを防ぐために、変更可能に変更可能になる必要があります。あるいは、アプリケーションはAPI呼び出しを介して直接変更可能に設定またはクリアできます。
Performing these steps before an active or passive open causes UTO options to be exchanged in the SYN and SYN-ACK packets and is a reliable way to initially exchange, and potentially adapt to, UTO values. TCP implementations MAY provide system-wide default settings for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.
アクティブまたはパッシブオープンの前にこれらの手順を実行すると、UTOオプションはSynおよびSyn-ackパケットで交換され、最初にUTO値を交換し、潜在的に適応する信頼できる方法です。TCP実装は、有効化、ADV_UTO、および変更可能な接続パラメーターのシステム全体のデフォルト設定を提供する場合があります。
In addition to exchanging UTO options in the SYN segments, a connection that has enabled UTO options SHOULD include a UTO option in the first packet that does not have the SYN flag set. This helps to minimize the amount of state information TCP must keep for connections in non-synchronized states. Also, it is particularly useful when mechanisms such as "SYN cookies" [RFC4987] are implemented, allowing a newly-established TCP connection to benefit from the information advertised by the UTO option, even if the UTO contained in the initial SYN segment was not recorded.
SynセグメントのUTOオプションを交換することに加えて、UTOオプションを有効にした接続には、Synフラグセットがない最初のパケットにUTOオプションを含める必要があります。これにより、TCPが非同期状態の接続のために保持する必要がある状態情報の量を最小限に抑えるのに役立ちます。また、「syn cookie」[RFC4987]などのメカニズムが実装されている場合に特に役立ち、新しく確立されたTCP接続がUTOオプションによって宣伝されている情報から利益を得ることができます。録音。
A host that supports the UTO option SHOULD include one in the next possible outgoing segment whenever it starts using a new user timeout for the connection. This allows the other end of the connection to adapt its local user timeout accordingly. A TCP implementation that does not support the UTO option MUST silently ignore it [RFC1122], thus ensuring interoperability.
UTOオプションをサポートするホストは、接続の新しいユーザータイムアウトの使用を開始するたびに、次の可能な発信セグメントに1つを含める必要があります。これにより、接続の反対側がそれに応じてローカルユーザーのタイムアウトを適合させることができます。UTOオプションをサポートしないTCP実装は、静かに無視する必要があります[RFC1122]したがって、相互運用性を確保する必要があります。
Hosts MUST impose upper and lower limits on the user timeouts they use for a connection. Section 3.1 discusses user timeout limits and potentially problematic effects of some user timeout settings.
ホストは、接続に使用するユーザーのタイムアウトに上限と下限を課す必要があります。セクション3.1では、ユーザーのタイムアウト制限と、一部のユーザータイムアウト設定の潜在的に問題のある効果について説明します。
Finally, it is worth noting that TCP's option space is limited to 40 bytes. As a result, if other TCP options are in use, they may already consume all the available TCP option space, thus preventing the use of the UTO option specified in this document. Therefore, TCP option space issues should be considered before enabling the UTO option.
最後に、TCPのオプションスペースが40バイトに制限されていることは注目に値します。その結果、他のTCPオプションが使用されている場合、利用可能なすべてのTCPオプションスペースをすでに消費する可能性があるため、このドキュメントで指定されたUTOオプションの使用が妨げられます。したがって、UTOオプションを有効にする前に、TCPオプションスペースの問題を考慮する必要があります。
When a host receives a TCP User Timeout Option, it must decide whether to change the local user timeout of the corresponding connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT be changed, regardless of the received UTO option. Without this restriction, the UTO option would modify TCP semantics, because an application-requested USER TIMEOUT could be overridden by peer requests. In this case TCP SHOULD, however, notify the application about the user timeout value received from the other end system.
ホストがTCPユーザータイムアウトオプションを受信した場合、対応する接続のローカルユーザータイムアウトを変更するかどうかを決定する必要があります。変更可能なフラグがfalseの場合、user_timeoutを受信したUTOオプションに関係なく、変更してはなりません。この制限がなければ、アプリケーションが要求されたユーザータイムアウトをピアリクエストによってオーバーライドできるため、UTOオプションはTCPセマンティクスを変更します。この場合、TCPは、反対側のシステムから受信したユーザーのタイムアウト値についてアプリケーションに通知する必要があります。
In general, unless the application on the local host has requested a specific USER TIMEOUT for the connection, CHANGEABLE will be true and hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in response to receiving a UTO option, as described in the remainder of this section.
一般に、ローカルホストのアプリケーションが接続の特定のユーザータイムアウトを要求していない限り、変更可能な変更可能であり、ホストは残りのオプションの受信に応じてローカルTCPユーザータイムアウト（user_timeout）を調整する必要があります。このセクション。
The UTO option specifies the user timeout in seconds or minutes, rather than in number of retransmissions or round-trip times (RTTs). Thus, the UTO option allows hosts to exchange user timeout values from 1 second to over 9 hours at a granularity of seconds, and from 1 minute to over 22 days at a granularity of minutes.
UTOオプションは、再送信の数や往復時間（RTT）ではなく、数秒または数分でユーザーのタイムアウトを指定します。したがって、UTOオプションを使用すると、ホストは秒数秒で1秒から9時間以上、粒度の粒度で1分から22日以上を交換できます。
Very short USER TIMEOUT values can affect TCP transmissions over high-delay paths. If the user timeout occurs before an acknowledgment for an outstanding segment arrives, possibly due to packet loss, the connection closes. Many TCP implementations default to USER TIMEOUT values of a few minutes. Although the UTO option allows suggestion of short timeouts, applications advertising them should consider these effects.
非常に短いユーザーのタイムアウト値は、高遅延パス上のTCP送信に影響を与える可能性があります。おそらくパケットの損失のために、未解決のセグメントの承認が到着する前にユーザーのタイムアウトが発生した場合、接続は閉じます。多くのTCP実装は、数分のユーザータイムアウト値にデフォルトです。UTOオプションは短いタイムアウトの提案を許可していますが、それらを宣伝するアプリケーションはこれらの効果を考慮する必要があります。
Long USER TIMEOUT values allow hosts to tolerate extended periods without end-to-end connectivity. However, they also require hosts to maintain the TCP state information associated with connections for long periods of time. Section 6 discusses the security implications of long timeout values.
長いユーザータイムアウト値により、ホストはエンドツーエンドの接続なしで長期間に耐えることができます。ただし、接続に関連するTCP状態情報を長期間維持するために、ホストにも必要です。セクション6では、長いタイムアウト値のセキュリティへの影響について説明します。
To protect against these effects, implementations MUST impose limits on the user timeout values they accept and use. The remainder of this section describes a RECOMMENDED scheme to limit TCP's USER TIMEOUT based on upper and lower limits.
これらの効果から保護するには、実装が受け入れて使用するユーザーのタイムアウト値に制限を課す必要があります。このセクションの残りの部分では、上限と下限に基づいてTCPのユーザータイムアウトを制限する推奨スキームについて説明します。
Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end SHOULD compute the local USER TIMEOUT for a connection according to this formula:
推奨されるスキームの下で、そして変更可能な場合、各端は、この式に従って接続のローカルユーザータイムアウトを計算する必要があります。
USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))
Each field is to be interpreted as follows:
各フィールドは次のように解釈されます。
USER_TIMEOUT USER TIMEOUT value to be adopted by the local TCP for this connection.
user_timeoutこの接続のためにローカルTCPで採用されるユーザータイムアウト値。
U_LIMIT Current upper limit imposed on the user timeout of a connection by the local host.
u_limit現在の上限は、ローカルホストによる接続のユーザータイムアウトに課されます。
ADV_UTO User timeout advertised to the remote TCP peer in a TCP User Timeout Option.
ADV_UTOユーザータイムアウトTCPユーザータイムアウトオプションでリモートTCPピアに宣伝されています。
REMOTE_UTO Last user timeout value received from the other end in a TCP User Timeout Option.
remote_uto TCPユーザータイムアウトオプションで反対側から受信した最後のユーザータイムアウト値。
L_LIMIT Current lower limit imposed on the user timeout of a connection by the local host.
L_LIMITローカルホストによる接続のユーザータイムアウトに課される電流下限。
The RECOMMENDED formula results in the maximum of the two advertised values, adjusted for the configured upper and lower limits, to be adopted for the user timeout of the connection on both ends. The rationale is that choosing the maximum of the two values will let the connection survive longer periods without end-to-end connectivity. If the end that announced the lower of the two user timeout values did so in order to reduce the amount of TCP state information that must be kept on the host, it can close or abort the connection whenever it wants.
推奨される式は、構成された上限と下限に合わせて調整された2つの広告値の最大値をもたらし、両端の接続のユーザータイムアウトに採用されます。理論的根拠は、2つの値の最大値を選択すると、エンドツーエンドの接続なしで接続がより長い期間に耐えることができるということです。2つのユーザータイムアウト値のうち低いことを発表した終了が、ホストに保持する必要があるTCP状態情報の量を減らすためにそうした場合、いつでも必要なときに接続を閉じたり中止したりできます。
It must be noted that the two endpoints of the connection will not necessarily adopt the same user timeout.
接続の2つのエンドポイントは、必ずしも同じユーザータイムアウトを採用するわけではないことに注意する必要があります。
Enforcing a lower limit (L_LIMIT) prevents connections from closing due to transient network conditions, including temporary congestion, mobility hand-offs, and routing instabilities.
下限（L_LIMIT）を実施すると、一時的な混雑、モビリティハンドオフ、ルーティング不安定性など、一時的なネットワーク条件のために接続が閉じることができなくなります。
An upper limit (U_LIMIT) can reduce the effect of resource exhaustion attacks. Section 6 discusses the details of these attacks.
上限（U_LIMIT）は、リソースの疲労攻撃の影響を減らすことができます。セクション6では、これらの攻撃の詳細について説明します。
Note that these limits MAY be specified as system-wide constants or at other granularities, such as on per-host, per-user, per-outgoing-interface, or even per-connection basis. Furthermore, these limits need not be static. For example, they MAY be a function of system resource utilization or attack status and could be dynamically adapted.
これらの制限は、システム全体の定数として、またはホストごと、ユーザーごと、介入ごと、または接続ごとのベースなどの他の粒状として指定される場合があることに注意してください。さらに、これらの制限は静的である必要はありません。たとえば、それらはシステムリソースの利用または攻撃ステータスの関数である可能性があり、動的に適応することができます。
The Host Requirements RFC [RFC1122] does not impose any limits on the length of the user timeout. However, it recommends a time interval of at least 100 seconds. Consequently, the lower limit (L_LIMIT) SHOULD be set to at least 100 seconds when following the RECOMMENDED scheme described in this section. Adopting a user timeout smaller than the current retransmission timeout (RTO) for the connection would likely cause the connection to be aborted unnecessarily. Therefore, the lower limit (L_LIMIT) MUST be larger than the current retransmission timeout (RTO) for the connection. It is worth noting that an upper limit may be imposed on the RTO, provided it is at least 60 seconds [RFC2988].
ホスト要件RFC [RFC1122]は、ユーザーのタイムアウトの長さに制限を課しません。ただし、少なくとも100秒の時間間隔を推奨します。したがって、このセクションで説明されている推奨スキームに従って、下限（L_LIMIT）を少なくとも100秒に設定する必要があります。接続の現在の再送信タイムアウト（RTO）よりも小さいユーザーのタイムアウトを採用すると、接続が不必要に中止される可能性があります。したがって、下限（L_LIMIT）は、接続の現在の再送信タイムアウト（RTO）よりも大きくなければなりません。少なくとも60秒であれば、RTOに上限が課される可能性があることは注目に値します[RFC2988]。
The TCP User Timeout Option is an advisory TCP option that does not change processing of subsequent segments. Unlike other TCP options, it need not be exchanged reliably. Consequently, the specification does not define a reliability handshake for UTO option exchanges. When a segment that carries a UTO option is lost, the other end will simply not have the opportunity to update its local USER TIMEOUT.
TCPユーザータイムアウトオプションは、後続のセグメントの処理を変更しないアドバイザリーTCPオプションです。他のTCPオプションとは異なり、確実に交換する必要はありません。したがって、仕様は、UTOオプション交換の信頼性の握手を定義するものではありません。UTOオプションを運ぶセグメントが失われた場合、もう一方の端は、ローカルユーザーのタイムアウトを更新する機会がありません。
Implementations MAY implement local mechanisms to improve delivery reliability, such as retransmitting a UTO option when they retransmit a segment that originally carried it, or "attaching" the option to a byte in the stream and retransmitting the option whenever that byte or its ACK are retransmitted.
実装は、元々それを運んだセグメントを再送信したときにUTOオプションを再送信するなど、配信の信頼性を改善するためのローカルメカニズムを実装したり、ストリーム内のバイトにオプションを「接続」したり、そのバイトまたはそのACKが再送信されるたびにオプションを再送信するなどします。。
It is important to note that although these mechanisms can improve transmission reliability for the UTO option, they do not guarantee delivery (a three-way handshake would be required for this). Consequently, implementations MUST NOT assume that UTO options are transmitted reliably.
これらのメカニズムはUTOオプションの伝送の信頼性を改善できるが、配信を保証するものではないことに注意することが重要です（これには3方向の握手が必要です）。したがって、実装は、UTOオプションが確実に送信されると仮定してはなりません。
Sending a TCP User Timeout Option informs the other end of the connection of the current local user timeout and suggests that the other end adapt its user timeout accordingly. The user timeout value included in a UTO option contains the ADV_UTO value that is expected to be adopted for the TCP's USER TIMEOUT parameter during the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other states MUST use the default timeout values defined in [RFC0793] and [RFC1122].
TCPユーザータイムアウトオプションを送信すると、現在のローカルユーザータイムアウトの接続の反対側に通知され、それに応じて他の端がユーザーのタイムアウトを適応させることを提案します。UTOオプションに含まれるユーザーのタイムアウト値には、接続の同期状態（確立、FIN-WAIT-1、FIN-WAIT-2、近い待機中にTCPのユーザータイムアウトパラメーターに採用されると予想されるADV_UTO値が含まれています、閉鎖、またはlast-ack）。他の状態の接続は、[RFC0793]および[RFC1122]で定義されたデフォルトのタイムアウト値を使用する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 28 | Length = 4 |G| User Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(One tick mark represents one bit.)
（1つのティックマークは1つのマークを表します。）
Figure 1: Format of the TCP User Timeout Option
図1：TCPユーザータイムアウトオプションの形式
Figure 1 shows the format of the TCP User Timeout Option. It contains these fields:
図1は、TCPユーザータイムアウトオプションの形式を示しています。これらのフィールドが含まれています。
Kind (8 bits) This MUST be 28, i.e., the TCP option number [RFC0793] that has been assigned by IANA (see Section 7).
Kind（8ビット）これは28でなければなりません。つまり、IANAによって割り当てられたTCPオプション番号[RFC0793]です（セクション7を参照）。
Length (8 bits) Length of the TCP option in octets [RFC0793]; its value MUST be 4.
オクテットのTCPオプションの長さ（8ビット）長さ[RFC0793];その価値は4でなければなりません。
Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds.
粒度（1ビット）粒度ビット。「ユーザータイムアウト」フィールドの粒度を示します。設定（g = 1）の場合、「ユーザータイムアウト」フィールドの時間間隔は議事録として解釈する必要があります。それ以外の場合は、（g = 0）、「ユーザータイムアウト」フィールドの時間間隔は秒として解釈する必要があります。
User Timeout (15 bits) Specifies the user timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field.
ユーザータイムアウト（15ビット）この接続のユーザータイムアウトの提案を指定します。15ビットの署名のない整数として解釈する必要があります。タイムアウトの粒度（数分または秒）は、「G」フィールドに依存します。
A TCP User Timeout Option with a "User Timeout" field of zero and a "Granularity" bit of either minutes (1) or seconds (0) is reserved for future use. Current TCP implementations MUST NOT send it and MUST ignore it upon reception.
ゼロの「ユーザータイムアウト」フィールドと数分（1）または秒（0）の「粒度」ビットを備えたTCPユーザータイムアウトオプションは、将来の使用のために予約されています。現在のTCP実装は送信してはなりません。受信時に無視する必要があります。
This section discusses interoperability issues related to introducing the TCP User Timeout Option.
このセクションでは、TCPユーザータイムアウトオプションの導入に関連する相互運用性の問題について説明します。
A TCP implementation that does not support the TCP User Timeout Option MUST silently ignore it [RFC1122], thus ensuring interoperability. In a study of the effects of middleboxes on transport protocols, Medina et al. have shown that the vast majority of modern TCP stacks correctly handle unknown TCP options [MEDINA]. In this study, 3% of connections failed when an unknown TCP option appeared in the middle of a connection. Because the number of failures caused by unknown options is small and they are a result of incorrectly implemented TCP stacks that violate existing requirements to ignore unknown options, they do not warrant special measures. Thus, this document does not define a mechanism to negotiate support of the TCP User Timeout Option during the three-way handshake.
TCPユーザータイムアウトオプションをサポートしないTCP実装は、静かにそれを無視する必要があります[RFC1122]したがって、相互運用性を確保する必要があります。輸送プロトコルに対するミドルボックスの効果の研究では、Medina et al。最新のTCPスタックの大部分が不明なTCPオプションを正しく処理することを示しました[Medina]。この研究では、接続の3％が接続の途中に表示されたときに接続の3％が失敗しました。不明なオプションによって引き起こされる障害の数は小さく、既存の要件に違反して不明なオプションを無視するために誤って実装されたTCPスタックの結果であるため、特別な措置は保証されません。したがって、このドキュメントは、3方向の握手中にTCPユーザータイムアウトオプションのサポートを交渉するメカニズムを定義するものではありません。
Implementations may want to exchange UTO options on the very first data segments after the three-way handshake to determine if such a middlebox exists on the path. When segments carrying UTO options are persistently lost, an implementation should turn off the use of UTO for the connection. When the connection itself is reset, an implementation may be able to transparently re-establish another connection instance that does not use UTO before any application data has been successfully exchanged.
実装は、3方向の握手の後に最初のデータセグメントでUTOオプションを交換して、そのようなミドルボックスがパスに存在するかどうかを判断することをお勧めします。UTOオプションを運ぶセグメントが永続的に失われる場合、実装は接続のためにUTOの使用をオフにする必要があります。接続自体がリセットされている場合、実装により、アプリケーションデータが正常に交換される前にUTOを使用しない別の接続インスタンスを透過的に再確立できる場合があります。
Stateful firewalls usually time out connection state after a period of inactivity. If such a firewall exists along the path, it may close or abort connections regardless of the use of the TCP User Timeout Option. In the future, such firewalls may learn to parse the TCP User Timeout Option in unencrypted TCP segments and adapt connection state management accordingly.
ステートフルファイアウォールは通常、非アクティブな期間の後に接続状態をタイムアウトします。このようなファイアウォールがパスに沿って存在する場合、TCPユーザータイムアウトオプションの使用に関係なく、接続を閉じたり中止したりする場合があります。将来的には、このようなファイアウォールは、暗号化されていないTCPセグメントのTCPユーザータイムアウトオプションを解析し、それに応じて接続状態管理を適応させることを学ぶかもしれません。
Some TCP implementations, such as those in BSD systems, use a different abort policy for TCP keep-alives than for user data. Thus, the TCP keep-alive mechanism might abort a connection that would otherwise have survived the transient period without connectivity. Therefore, if a connection that enables keep-alives is also using the TCP User Timeout Option, then the keep-alive timer MUST be set to a value larger than that of the adopted USER TIMEOUT.
BSD SystemsのようなTCP実装の一部は、ユーザーデータよりもTCP Keep-Alivesに異なる中止ポリシーを使用しています。したがって、TCP Keep-Aliveメカニズムは、他の方法では接続なしで過渡期間を生き延びたであろう接続を中止する可能性があります。したがって、Keep-Alivesを有効にする接続がTCPユーザータイムアウトオプションを使用している場合、Keep-Aliveタイマーは、採用されたユーザータイムアウトの値よりも大きい値に設定する必要があります。
The IETF specification for TCP [RFC0793] includes a simple, abstract application programming interface (API). Similarly, the API for the UTO extension in Section 3 is kept abstract. TCP implementations, however, usually provide more complex and feature-rich APIs. The "socket" API that originated with BSD Unix and is now standardized by POSIX is one such example [POSIX]. It is expected that TCP implementations that choose to include the UTO extension will extend their API to allow applications to use and configure its parameters.
TCP [RFC0793]のIETF仕様には、シンプルで抽象的なアプリケーションプログラミングインターフェイス（API）が含まれています。同様に、セクション3のUTO拡張のAPIは抽象的に保たれます。ただし、TCP実装は通常、より複雑で機能が豊富なAPIを提供します。BSD UNIXで発信され、現在POSIXによって標準化された「Socket」APIは、そのような例[POSIX]の1つです。UTO拡張機能を含めることを選択するTCP実装により、APIが拡張され、アプリケーションがパラメーターを使用および構成できるようにすることが期待されます。
The MIB objects defined in [RFC4022] and [RFC4898] allow management of TCP connections. It is expected that revisions to these documents will include definitions of objects for managing the UTO extension defined in this document.
[RFC4022]および[RFC4898]で定義されているMIBオブジェクトは、TCP接続の管理を可能にします。これらのドキュメントの改訂には、このドキュメントで定義されているUTO拡張機能を管理するためのオブジェクトの定義が含まれることが期待されています。
Lengthening user timeouts has obvious security implications. Flooding attacks cause denial of service by forcing servers to commit resources for maintaining the state of throw-away connections. However, TCP implementations do not become more vulnerable to simple SYN flooding by implementing the TCP User Timeout Option, because user timeouts exchanged during the handshake only affect the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), which simple SYN floods never reach.
ユーザーのタイムアウトの延長には、明らかなセキュリティへの影響があります。洪水攻撃により、サーバーに捨てられた接続の状態を維持するためのリソースをコミットすることを強制することにより、サービスの拒否を引き起こします。ただし、TCPの実装は、TCPユーザータイムアウトオプションを実装することにより、単純なSynフラッディングに対して脆弱になることはありません。これは、ハンドシェイク中に交換されるユーザーのタイムアウトが同期状態にのみ影響するためです（Fin-Wait-1、Fin-Wait-2、Close-待って、閉じて、最後の問題）、単純なsyn洪水が届かない。
However, when an attacker completes the three-way handshakes of its throw-away connections, it can amplify the effects of resource exhaustion attacks because the attacked server must maintain the connection state associated with the throw-away connections for longer durations. Because connection state is kept longer, lower-frequency attack traffic, which may be more difficult to detect, can already exacerbate resource exhaustion.
ただし、攻撃者がスローアウェイ接続の3方向の握手を完了すると、攻撃されたサーバーは、より長い期間にわたってスローアウェイ接続に関連付けられた接続状態を維持する必要があるため、リソース排出攻撃の効果を増幅できます。接続状態は長く維持されているため、検出がより困難になる可能性のある低周波攻撃トラフィックは、リソースの疲労をすでに悪化させる可能性があります。
Several approaches can help mitigate this issue. First, implementations can require prior peer authentication, e.g., using IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user timeouts for the peer's connections. (Implementors that decide to use TCP-MD5 for this purpose are encouraged to monitor the development of TCP-AO [AUTH_OPT], its designated successor, and update their implementation when it is published as an RFC.) A similar approach is for a host to start accepting long user timeouts for an established connection only after in-band authentication has occurred, for example, after a TLS handshake across the connection has succeeded [RFC5246]. Although these are arguably the most complete solutions, they depend on external mechanisms to establish a trust relationship.
いくつかのアプローチは、この問題を軽減するのに役立ちます。まず、実装では、ピアの接続の長いユーザーのタイムアウトを受け入れる前に、IPSEC [RFC4301]またはTCP-MD5 [RFC2385]を使用して、以前のピア認証を必要とする場合があります。（この目的のためにTCP-MD5を使用することを決定した実装者は、指定された後継者であるTCP-AO [auth_opt]の開発を監視し、RFCとして公開されたときに実装を更新することをお勧めします。）同様のアプローチはホストの場合です。たとえば、接続全体のTLSの握手が成功した後、インバンド認証が発生した後にのみ、確立された接続の長いユーザータイムアウトの受け入れを開始するために[RFC5246]。これらは間違いなく最も完全な解決策ですが、信頼関係を確立するための外部メカニズムに依存しています。
A second alternative that does not depend on external mechanisms would introduce a per-peer limit on the number of connections that may use increased user timeouts. Several variants of this approach are possible, such as fixed limits or shortening accepted user timeouts with a rising number of connections. Although this alternative does not eliminate resource exhaustion attacks from a single peer, it can limit their effects. Reducing the number of high-UTO connections a server supports in the face of an attack turns that attack into a denial-of-service attack against the service of high-UTO connections.
外部メカニズムに依存しない2番目の代替案は、ユーザーのタイムアウトの増加を使用する可能性のある接続の数にピアごとの制限を導入します。このアプローチのいくつかのバリエーションは、固定制限や、接続の数が増加している受け入れられたユーザータイムアウトなど、可能になります。この代替手段は、単一のピアからのリソース疲労攻撃を排除するものではありませんが、効果を制限する可能性があります。攻撃に直面してサーバーがサポートする高UTO接続の数を減らすと、その攻撃は、高UTO接続のサービスに対するサービス拒否攻撃に変わります。
Per-peer limits cannot protect against distributed denial-of-service attacks, where multiple clients coordinate a resource exhaustion attack that uses long user timeouts. To protect against such attacks, TCP implementations could reduce the duration of accepted user timeouts with increasing resource utilization.
ピアごとの制限は、分散型のサービス拒否攻撃から保護することはできません。複数のクライアントが長いユーザーのタイムアウトを使用するリソースの消耗攻撃を調整します。このような攻撃から保護するために、TCPの実装は、リソースの使用率が向上すると、受け入れられているユーザータイムアウトの期間を短縮する可能性があります。
TCP implementations under attack may be forced to shed load by resetting established connections. Some load-shedding heuristics, such as resetting connections with long idle times first, can negatively affect service for intermittently connected, trusted peers that have suggested long user timeouts. On the other hand, resetting connections to untrusted peers that use long user timeouts may be effective. In general, using the peers' level of trust as a parameter during the load-shedding decision process may be useful. Note that if TCP needs to close or abort connections with a long TCP User Timeout Option to shed load, these connections are still no worse off than without the option.
攻撃中のTCP実装は、確立された接続をリセットすることにより、負荷を削減することを余儀なくされる場合があります。最初に長いアイドル時間との接続をリセットするなど、一部の負荷抑制ヒューリスティックは、長いユーザーのタイムアウトを示唆する断続的に接続された信頼できるピアのサービスに悪影響を与える可能性があります。一方、長いユーザータイムアウトを使用する信頼できないピアへの接続をリセットすることが効果的かもしれません。一般に、負荷抑制決定プロセス中にピアのレベルの信頼をパラメーターとして使用することが役立つ場合があります。TCPは、長いTCPユーザータイムアウトオプションで接続を閉じたり中止したりする必要がある場合、これらの接続はオプションがないよりも悪化していないことに注意してください。
Finally, upper and lower limits on user timeouts, discussed in Section 3.1, can be an effective tool to limit the impact of these sorts of attacks.
最後に、セクション3.1で説明されているユーザーのタイムアウトの上限と下限は、これらの種類の攻撃の影響を制限するための効果的なツールになる可能性があります。
This section is to be interpreted according to [RFC5226].
このセクションは、[RFC5226]に従って解釈されます。
This document does not define any new namespaces. IANA has allocated a new 8-bit TCP option number (28) for the UTO option from the "TCP Option Kind Numbers" registry maintained at http://www.iana.org.
このドキュメントは、新しい名前空間を定義しません。IANAは、http://www.iana.orgに維持されている「TCPオプション種類番号」レジストリから、UTOオプションに新しい8ビットTCPオプション番号（28）を割り当てました。
The following people have improved this document through thoughtful suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard, and Martin Stiemerling.
次の人々は、思慮深い提案を通じてこの文書を改善しました：マーク・オールマン、ケイトリン・ベストラー、デビッド・ボーマン、ボブ・ブレイデン、スコット・ブリム、マーカス・ブルナー、ウェスリー・エディ、ゴリー・フェアハースト、アボラード・グバデゲシン、テッド・ファーバー、ギレモ・ゴント、トム・ヘンダーソン、ジョセフ・イシャックジェレミー・ハリス、アルフレッド・ホーネス、フィル・カーン、マイケル・ケリスク、ダン・クレジサ、ジャムシッド・マフダヴィ、コスタス・ペンティクーシス、ジュエルゲン・キッテク、アナンサ・ラマイア、ジョー・タッチ、ステファン・シュミット、サイモン・シューッツ、ティム・シェパード、マーティン・スティンルーリング。
Lars Eggert is partly funded by [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program.
Lars Eggertは、7番目のフレームワークプログラムに基づいて欧州委員会がサポートする研究プロジェクトである[Trilogy]によって部分的に資金提供されています。
Fernando Gont wishes to thank Secretaria de Extension Universitaria at Universidad Tecnologica Nacional and Universidad Tecnologica Nacional/Facultad Regional Haedo for supporting him in this work.
Fernando Gontは、この作品で彼を支援してくれたことに、Universidad tecnologica nacionalとUniversidad tecnologica nacional/fanfultad Regional HaedoのSecre Secreceraria de Extension Universitariaに感謝したいと考えています。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[AUTH_OPT] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Work in Progress, November 2008.
[Auth_opt] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、2008年11月、Work in Progress。
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004.
[Medina] Medina、A.、Allman、M。、およびS. Floyd、「輸送プロトコルとミドルボックス間の相互作用の測定」、Proc。2004年10月、インターネット測定に関する第4回ACM SIGCOMM/USENIX会議。
[POSIX] IEEE Std. 1003.1-2001, "Standard for Information Technology - Portable Operating System Interface (POSIX)", Open Group Technical Standard: Base Specifications Issue 6, ISO/IEC 9945:2002, December 2001.
[posix] IEEE std。1003.1-2001、「情報技術の標準 - ポータブルオペレーティングシステムインターフェイス（POSIX）」、オープングループ技術標準：基本仕様問題6、ISO/IEC 9945：2002、2001年12月。
[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月。
[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月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022] Raghunarayan、R。、「送信制御プロトコルの管理情報ベース（TCP）」、RFC 4022、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[RFC4898] Mathis、M.、Heffner、J。、およびR. Raghunarayan、「TCP拡張統計MIB」、RFC 4898、2007年5月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[SOLARIS] Sun Microsystems, "Solaris Tunable Parameters Reference Manual", Part No. 806-7009-10, 2002.
[Solaris] Sun Microsystems、「Solaris Tuanable Parameters Reference Manual」、パート番号806-7009-10、2002。
[TCP_MOB] Eddy, W., "Mobility Support For TCP", Work in Progress, April 2004.
[TCP_MOB] Eddy、W。、「TCPのモビリティサポート」、2004年4月、進行中の作業。
[TRILOGY] "Trilogy Project", <http://www.trilogy-project.org/>.
[Trilogy]「Trilogy Project」、<http://www.trilogy-project.org/>。
Authors' Addresses
著者のアドレス
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
Lars Eggert Nokia Research Center P.O.Box 407 Nokia Group 00045フィンランド
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンド・ゴント大学テクノロジカ・ナシオナル /ファカルカル地域ハード・エヴァリスト・キャリーゴ2644ハード、地方de buenos Aires 1706 Argentina
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar/