Network Working Group W. Eddy
Request for Comments: 4987 Verizon
Category: Informational August 2007
TCP SYN Flooding Attacks and Common Mitigations
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.
この文書では、数年前から地域社会に周知されているTCP SYNフラッディング攻撃を、説明しています。様々なこれらの攻撃対策、及びそれぞれのトレードオフは、記載されています。このドキュメントはTCPの実装とTCPサーバーやネットワークの管理者の利益のために攻撃と共通防衛技術のアーカイブの説明は、任意の標準レベルの勧告を行いません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 2
2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 3
3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Increasing Backlog . . . . . . . . . . . . . . . . . . . . 7
3.3. Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 7
3.4. Recycling the Oldest Half-Open TCB . . . . . . . . . . . . 7
3.5. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10
3.8. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 16
The SYN flooding attack is a denial-of-service method affecting hosts that run TCP server processes. The attack takes advantage of the state retention TCP performs for some time after receiving a SYN segment to a port that has been put into the LISTEN state. The basic idea is to exploit this behavior by causing a host to retain enough state for bogus half-connections that there are no resources left to establish new legitimate connections.
SYNフラッド攻撃は、TCPサーバー・プロセスを実行するホストに影響を与えるサービス拒否の方法です。攻撃は状態保持TCPを利用していますLISTEN状態に置かれているポートにSYNセグメントを受信した後、いくつかの時間のために実行されます。基本的な考え方は、新しい正当な接続を確立するために左にリソースがないことを偽の半分接続のための十分な状態を維持するホストを引き起こすことによって、この動作を利用することです。
This SYN flooding attack has been well-known to the community for many years, and has been observed in the wild by network operators and end hosts. A number of methods have been developed and deployed to make SYN flooding less effective. Despite the notoriety of the attack, and the widely available countermeasures, the RFC series only documented the vulnerability as an example motivation for ingress filtering [RFC2827], and has not suggested any mitigation techniques for TCP implementations. This document addresses both points, but does not define any standards. Formal specifications and requirements of defense mechanisms are outside the scope of this document. Many defenses only impact an end host's implementation without changing interoperability. These may not require standardization, but their side-effects should at least be well understood.
このSYNフラッド攻撃は、長年にわたって社会に周知されており、ネットワーク事業者とエンドホストによって野生で観察されています。多くの方法が開発され、SYNフラッドはあまり効果的にするために配備されています。攻撃の悪評、広く利用可能な対策にもかかわらず、RFCシリーズは、侵入フィルタ[RFC2827]のための例示的な動機として脆弱性を文書化し、TCPの実装のための任意の緩和技術を提案していません。この文書では、両方のポイントに対処しますが、任意の標準を定義していません。防御機構の正式な仕様と要件は、この文書の範囲外です。多くの防御だけで、相互運用性を変更することなく、エンドホストの実装に影響を与えます。これらは、標準化を必要としないかもしれないが、その副作用は、少なくとも十分に理解されるべきです。
This document intentionally focuses on SYN flooding attacks from an individual end host or application's perspective, as a means to deny service to that specific entity. High packet-rate attacks that target the network's packet-processing capability and capacity have been observed operationally. Since such attacks target the network, and not a TCP implementation, they are out of scope for this document, whether or not they happen to use TCP SYN segments as part of the attack, as the nature of the packets used is irrelevant in comparison to the packet-rate in such attacks.
この文書では、意図的にその特定のエンティティへのサービスを拒否するための手段として、個々のエンドホストやアプリケーションの観点からSYNフラッド攻撃に焦点を当てています。ネットワークのパケット処理能力や容量をターゲット高いパケットレート攻撃は運用観察されています。このような攻撃は、ネットワークではなく、TCPの実装を標的とするので、それらが使用されるパケットの性質はと比較して無関係であるようにそれらは、攻撃の一部としてTCP SYNセグメントを使用するように起こるかどうか、この文書の範囲外でありますこのような攻撃でのパケットレート。
The majority of this document consists of three sections. Section 2 explains the SYN flooding attack in greater detail. Several common mitigation techniques are described in Section 3. An analysis and discussion of these techniques and their use is presented in Section 4. Further information on SYN cookies is contained in Appendix A.
このドキュメントの大半は3つのセクションから構成されています。第2節では、より詳細にSYNフラッド攻撃について説明します。いくつかの一般的な緩和技術は、第3節ではこれらの技術の分析と議論を記載されており、その使用は、SYNクッキーの詳細については、付録Aに含まれている第4項に提示されています
This section describes both the history and the technical basis of the SYN flooding attack.
このセクションでは、歴史やSYNフラッド攻撃の技術的基礎の両方を説明しています。
The TCP SYN flooding weakness was discovered as early as 1994 by Bill Cheswick and Steve Bellovin [B96]. They included, and then removed, a paragraph on the attack in their book "Firewalls and Internet Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no countermeasures were developed within the next two years.
TCP SYNフラッドの弱点は、ビルチェスウィックとスティーブBellovin氏[B96]で、早ければ1994年のように発見されました。彼らは含まれており、除去、彼らの著書「ファイアウォールとインターネットセキュリティ：ワイリーハッカーを撃退」の攻撃の段落[CB94]。残念ながら、対策は今後2年以内に開発されませんでした。
The SYN flooding attack was first publicized in 1996, with the release of a description and exploit tool in Phrack Magazine [P48-13]. Aside from some minor inaccuracies, this article is of high enough quality to be useful, and code from the article was widely distributed and used.
SYNフラッド攻撃は、最初の説明をリリースし、1996年に公表し、Phrackマガジン[P48-13]でツールを悪用しました。別にいくつかのマイナーな不正確から、この記事では有用であることが十分に高い品質のものであり、記事からコードが広く分布して使用しました。
By September of 1996, SYN flooding attacks had been observed in the wild. Particularly, an attack against one ISP's mail servers caused well-publicized outages. CERT quickly released an advisory on the attack [CA-96.21]. SYN flooding was particularly serious in comparison to other known denial-of-service attacks at the time. Rather than relying on the common brute-force tactic of simply exhausting the network's resources, SYN flooding targets end-host resources, which require fewer packets to deplete.
1996年9月までに、SYNフラッド攻撃は野生で観察されていました。特に、1台のISPのメールサーバに対する攻撃は、広く公表停止を引き起こしました。 CERTはすぐに攻撃[CA-96.21]上の助言をリリースしました。 SYNフラッドは、一度に他の既知のサービス拒否攻撃と比較して特に深刻でした。むしろ、単にネットワークのリソースを排出する一般的なブルートフォース戦術に頼るよりも、少数のパケットを必要とSYNフラッドのターゲットエンドホストのリソースは、枯渇します。
The community quickly developed many widely differing techniques for preventing or limiting the impact of SYN flooding attacks. Many of these have been deployed to varying degrees on the Internet, in both end hosts and intervening routers. Some of these techniques have become important pieces of the TCP implementations in certain operating systems, although some significantly diverge from the TCP specification and none of these techniques have yet been standardized or sanctioned by the IETF process.
コミュニティはすぐにSYNフラッド攻撃の影響を防止または制限するための多くの広く異なる技術を開発しました。これらの多くは、エンドホストおよび介在ルータの両方で、インターネット上の様々な程度に配備されています。一部が大幅にTCPの仕様およびこれらの技術のどれから発散するが、これらの技術のいくつかは、まだIETFプロセスによって標準化または認可されており、特定のオペレーティング・システムにおけるTCPの実装の重要な部分となっています。
As described in RFC 793, a TCP implementation may allow the LISTEN state to be entered with either all, some, or none of the pair of IP addresses and port numbers specified by the application. In many common applications like web servers, none of the remote host's information is pre-known or preconfigured, so that a connection can be established with any client whose details are unknown to the server ahead of time. This type of "unbound" LISTEN is the target of SYN flooding attacks due to the way it is typically implemented by operating systems.
RFC 793に記載されているように、TCP実装はすべて、一部、またはアプリケーションによって指定されたIPアドレスとポート番号の対のいずれもいずれかで入力するLISTEN状態を可能にすることができます。接続がその詳細は事前にサーバーに不明である任意のクライアントを確立することができるように、Webサーバのような多くの一般的な用途では、リモートホストの情報はいずれも、事前に知られているか、あらかじめ設定されていません。 「結合していないが、」LISTENこのタイプのため、それは、通常、オペレーティング・システムによって実装される方法にSYNフラッド攻撃の対象です。
For success, the SYN flooding attack relies on the victim host TCP implementation's behavior. In particular, it assumes that the victim allocates state for every TCP SYN segment when it is received, and that there is a limit on the amount of such state than can be kept at any time. The current base TCP specification, RFC 793 [RFC0793], describes the standard processing of incoming SYN segments. RFC 793 describes the concept of a Transmission Control Block (TCB) data structure to store all the state information for an individual connection. In practice, operating systems may implement this concept rather differently, but the key is that each TCP connection requires some memory space.
成功のために、SYNフラッド攻撃は、被害者のホストのTCP実装の動作に依存しています。具体的には、それが受信した場合、被害者は、すべてのTCP SYNセグメントの状態を割り当てることを前提とし、いつでも維持することができるよりも、このような状態の量に限界があること。現在のベースTCP仕様は、RFC 793 [RFC0793]は、受信SYNセグメントの標準的な処理について説明します。 RFC 793は、個々の接続のためのすべての状態情報を格納するために伝送制御ブロック（TCB）のデータ構造の概念を説明しています。実際には、オペレーティング・システムはかなり異なっこの概念を実装することができますが、キーは、各TCP接続は、いくつかのメモリ空間を必要とすることです。
Per RFC 793, when a SYN is received for a local TCP port where a connection is in the LISTEN state, then the state transitions to SYN-RECEIVED, and some of the TCB is initialized with information from the header fields of the received SYN segment. In practice, many operating systems do not alter the TCB in LISTEN, but instead make a copy of the TCB and perform the state transition and update on the copy. This is done so that the local TCP port may be shared amongst several distinct connections. This TCB-copying behavior is not actually essential for this purpose, but influences the way in which applications that wish to handle multiple simultaneous connections through a single TCP port are written. The crucial result of this behavior is that, instead of updating already-allocated memory, new (or unused) memory must be devoted to the copied TCB.
RFCあたりのSYNは接続がLISTEN状態にあるローカルTCPポートに受信され793、SYN-受信され、状態遷移、及びTCBの一部は、受信されたSYNセグメントのヘッダフィールドからの情報で初期化されます。実際には、多くのオペレーティングシステムは、LISTENでTCBを変更し、代わりにTCBのコピーを作成し、そのコピーの状態遷移と更新を実行しないでください。ローカルTCPポートは、複数の別個の接続間で共有することができるようにするためです。このTCB-コピー動作は、この目的のために実際には必須ではないが、単一のTCPポートを介して複数の同時接続を処理したいアプリケーションが書かれている方法に影響を与えます。この動作の重要な結果ではなく、既に割り当てられたメモリを更新する、新しい（または未使用）メモリがコピーされたTCBに専念しなければならない、ということです。
As an example, in the Linux 2.6.10 networking code, a "sock" structure is used to implement the TCB concept. By examination, this structure takes over 1300 bytes to store in memory. In other systems that implement less-complex TCP algorithms and options, the overhead may be less, although it typically exceeds 280 bytes [SKK+97].
例として、Linuxの2.6.10ネットワークコードで、「靴下」構造は、TCBの概念を実装するために使用されます。検査では、この構造は、メモリに格納する1300バイト以上かかります。それは典型的には280バイト[SKK + 97]を超えているがあまり複雑なTCPアルゴリズムとオプションを実装する他のシステムでは、オーバーヘッドは小さくてもよいです。
To protect host memory from being exhausted by connection requests, the number of TCB structures that can be resident at any time is usually limited by operating system kernels. Systems vary on whether limits are globally applied or local to a particular port number. There is also variation on whether the limits apply to fully established connections as well as those in SYN-RECEIVED. Commonly, systems implement a parameter to the typical listen() system call that allows the application to suggest a value for this limit, called the backlog. When the backlog limit is reached, then either incoming SYN segments are ignored, or uncompleted connections in the backlog are replaced. The concept of using a backlog is not described in the standards documents, so the failure behavior when the backlog is reached might differ between stacks (for instance, TCP RSTs might be generated). The exact failure behavior will determine whether initiating hosts continue to retransmit SYN segments over time, or quickly cease. These differences in implementation are acceptable since they only affect the behavior of the local stack when its resources are constrained, and do not cause interoperability problems.
接続要求によって排出されるからホストメモリを保護するために、任意の時点で存在することができるTCB構造体の数は、通常、オペレーティングシステムのカーネルによって制限されています。システムは、制限がグローバルに特定のポート番号に適用されるか、ローカルであるかに変わります。制限が完全に接続だけでなく、SYN-RECEIVEDのものを確立するために適用するかどうかのバリエーションもあります。一般的に、システムは、バックログと呼ばれ、アプリケーションがこの制限値を提案することを可能にする典型的な聞く（）システムコールにパラメータを実装します。バックログの上限に達すると、その後のいずれかで受信SYNセグメントは無視され、またはバックログ内の未完了の接続が置換されています。バックログを使用しての概念は、規格文書に記述されていないので、バックログはスタックの間異なる場合があります達している障害時の動作（例えばは、TCPのRSTが生成される可能性があります）。障害の正確な動作が開始するホストが時間をかけてSYNセグメントを再送信し続けるかどうかを判断する、またはすぐに終了します。実装におけるこれらの違いは、彼らが唯一の資源が制約されているローカル・スタックの動作に影響を与えるので、許容され、および相互運用性の問題が発生することはありません。
The SYN flooding attack does not attempt to overload the network's resources or the end host's memory, but merely attempts to exhaust the backlog of half-open connections associated with a port number. The goal is to send a quick barrage of SYN segments from IP addresses (often spoofed) that will not generate replies to the SYN-ACKs that are produced. By keeping the backlog full of bogus half-opened connections, legitimate requests will be rejected. Three important attack parameters for success are the size of the barrage, the frequency with which barrages are generated, and the means of selecting IP addresses to spoof.
SYNフラッド攻撃は、ネットワークのリソースを過負荷状態にしようとか、エンドホストのメモリ、単にポート番号に関連付けられたハーフオープン接続のバックログを排出しようとしません。目標は、製造されているSYN-ACKのに応答を生成しません（多くの場合、偽装された）IPアドレスからのSYNセグメントの迅速な弾幕を送信することです。偽の半分開かれた接続のフルバックログを保持することにより、正当な要求は拒否されます。成功のための3つの重要な攻撃パラメータは、弾幕のサイズ、弾幕が生成される頻度、および偽装するIPアドレスを選択する手段です。
Barrage Size
弾幕サイズ
To be effective, the size of the barrage must be made large enough to reach the backlog. Ideally, the barrage size is no larger than the backlog, minimizing the volume of traffic the attacker must source. Typical default backlog values vary from a half-dozen to several dozen, so the attack might be tailored to the particular value determined by the victim host and application. On machines intended to be servers, especially for a high volume of traffic, the backlogs are often administratively configured to higher values.
効果的であるためには、弾幕のサイズは、バックログに到達するのに十分な大きさにしなければなりません。理想的には、堰のサイズは、攻撃者がソースなければならないトラフィックの量を最小限に抑える、バックログよりも大きくありません。典型的なデフォルトのバックログ値は数十に半ダースごとに異なり、その攻撃は、被害者のホストおよびアプリケーションによって決まる特定の値に合わせて調整することがあります。特に大量のトラフィックのために、サーバであることを意図したマシンでは、バックログは、多くの場合、管理高い値に設定されています。
Barrage Frequency
弾幕頻度
To limit the lifetime of half-opened connection state, TCP implementations commonly reclaim memory from half-opened connections if they do not become fully opened after some time period. For instance, a timer of 75 seconds [SKK+97] might be set when the first SYN-ACK is sent, and on expiration cause SYN-ACK retransmissions to cease and the TCB to be released. The TCP specifications do not include this behavior of giving up on connection establishment after an arbitrary time. Some purists have expressed that the TCP implementation should continue retransmitting SYN and SYN-ACK segments without artificial bounds (but with exponential backoff to some conservative rate) until the application gives up. Despite this, common operating systems today do implement some artificial limit on half-open TCB lifetime. For instance, backing off and stopping after a total of 511 seconds can be observed in 4.4 BSD-Lite [Ste95], and is still practiced in some operating systems derived from this code.
彼らは完全にいくつかの時間後に開かならない場合は半開き接続状態の寿命を制限するには、TCPの実装は、一般的に半分開かれた接続からメモリを解放します。最初のSYN-ACKが送信される際例えば、75秒[SKK + 97]のタイマーが設定されることがあり、かつ有効期限の原因にSYN-ACKの再送信を中止するとTCBがリリースされます。 TCPの仕様は、任意の時間の後に、接続の確立をあきらめるのこの動作は含まれていません。いくつかの純粋主義者は、アプリケーションがあきらめるまで、TCPの実装は（しかし、いくつかの保守的な速度に指数バックオフを有する）人工際限なくSYNおよびSYN-ACKセグメントを再送続けるべきであることを表明しています。それにもかかわらず、一般的なオペレーティングシステム、今日はハーフオープンTCBの寿命に何らかの人為的な制限を実装します。例えば、バックオフおよび511秒の合計が4.4 BSD-Liteの[Ste95]で観察することができ、さらにこのコードに由来するいくつかのオペレーティングシステムで実施された後に停止します。
To remain effective, a SYN flooding attack needs to send new barrages of bogus connection requests as soon as the TCBs from the previous barrage begin to be reclaimed. The frequency of barrages are tailored to the victim TCP implementation's TCB reclamation timer. Frequencies higher than needed source more packets, potentially drawing more attention, and frequencies that are too low will allow windows of time where legitimate connections can be established.
効果を持続するには、SYNフラッド攻撃は、再利用され始める前の弾幕からのTCBとすぐに偽の接続要求の新しい弾幕を送信する必要があります。弾幕の周波数は、被害者のTCP実装のTCB再利用タイマーに合わせました。必要なソースより多くのパケットよりも高い周波数、潜在的に多くの注目を集め、かつ低すぎる周波数は、正当な接続を確立することができる時間のウィンドウを許可します。
IP Address Selection
IPアドレスの選択
For an effective attack, it is important that the spoofed IP addresses be unresponsive to the SYN-ACK segments that the victim will generate. If addresses of normal connected hosts are used, then those hosts will send the victim a TCP reset segment that will immediately free the corresponding TCB and allow room in the backlog for legitimate connections to be made. The code distributed in the original Phrack article used a single source address for all spoofed SYN segments. This makes the attack segments somewhat easier to identify and filter. A strong attacker will have a list of unresponsive and unrelated addresses that it chooses spoofed source addresses from.
効果的な攻撃に対しては、偽装されたIPアドレスは、被害者が生成されますSYN-ACKセグメントに応答しないことが重要です。通常の接続ホストのアドレスが使用されている場合は、それらのホストは、被害者に即座に対応するTCBを解放して行うべき正当な接続のためにバックログでの部屋を許可するTCPリセットセグメントを送信します。オリジナルPhrack資料に分布したコードは、すべてのなりすましSYNセグメントの単一のソースアドレスを使用します。これは特定してフィルタに攻撃セグメントは多少容易になります。強力な攻撃者は、それから偽装された送信元アドレスを選択することに応答しないと関係のないアドレスのリストを持っています。
It is important to note that this attack is directed at particular listening applications on a host, and not the host itself or the network. The attack also attempts to prevent only the establishment of new incoming connections to the victim port, and does not impact outgoing connection requests, nor previously established connections to the victim port.
この攻撃は、ホストではなく、ホスト自体またはネットワーク上の特定のリスニング用途に向けられていることに注意することが重要です。攻撃はまた、被害者のポートへの新しい着信接続の唯一の確立を防ぐためにしようとすると、発信接続要求に影響を与えない、また以前に被害者のポートへの接続を確立しました。
In practice, an attacker might choose not to use spoofed IP addresses, but instead to use a multitude of hosts to initiate a SYN flooding attack. For instance, a collection of compromised hosts under the attacker's control (i.e., a "botnet") could be used. In this case, each host utilized in the attack would have to suppress its operating system's native response to the SYN-ACKs coming from the target. It is also possible for the attack TCP segments to arrive in a more continuous fashion than the "barrage" terminology used here suggests; as long as the rate of new SYNs exceeds the rate at which TCBs are reaped, the attack will be successful.
実際には、攻撃者が偽装されたIPアドレスを使用するが、代わりにSYNフラッド攻撃を開始するために、多数のホストを使用しないことを選択するかもしれません。例えば、攻撃者の制御下損なわホスト（すなわち、「ボットネット」）のコレクションを使用することができます。この場合、攻撃に利用される各ホストは、ターゲットからのSYN-ACKのへのオペレーティングシステムのネイティブの応答を抑制しなければなりません。攻撃TCPセグメントは、ここで使用される「弾幕」の用語が示唆する以上に連続的に到着することも可能です。限り、新しいSYNのレートはのTCBが享受される速度を超えると、攻撃が成功します。
This section discusses a number of defense techniques that are known to the community, many of which are available in off-the-shelf products.
このセクションでは、既製の製品で利用されているその多くのコミュニティに知られている防衛技術の数について説明します。
Since in the absence of an army of controlled hosts, the ability to send packets with spoofed source IP addresses is required for this attack to work, removing an attacker's ability to send spoofed IP packets is an effective solution that requires no modifications to TCP. The filtering techniques described in RFCs 2827, 3013, and 3704 represent the best current practices for packet filtering based on IP addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective, end hosts should not rely on filtering policies to prevent attacks from spoofed segments, as global deployment of filters is neither guaranteed nor likely. An attacker with the ability to use a group of compromised hosts or to rapidly change between different access providers will also make filtering an impotent solution.
この攻撃が機能するために、制御ホストの軍隊の不存在下で以来、偽装された送信元のIPアドレスを持つパケットを送信する機能は、偽装されたIPパケットを送信するために攻撃者の能力を取り除く、TCPへの変更を必要としない効果的なソリューションをである必要があります。 RFC 2827、3013、および3704に記載のフィルタリング技術は、[RFC2827]、[RFC3013]、[RFC3704] IPアドレスに基づいてパケットフィルタリングのための最善の現在のプラクティスを表します。フィルタのグローバル展開が保証もありそうもされていないよう完全に有効であるが、エンドホストは、偽装されたセグメントからの攻撃を防ぐためにフィルタリングポリシーに頼るべきではありません。妥協ホストのグループを使用するか、急速に異なるアクセス・プロバイダとの間で変更する能力を持つ攻撃者はまた、無力溶液を濾過するであろう。
An obvious attempt at a defense is for end hosts to use a larger backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some serious negative aspects as the size of the backlog grows [Lem02]. The implementation has not been designed to scale past backlogs of a few hundred, and the data structures and search algorithms that it uses are inefficient with larger backlogs. It is reasonable to assume that other TCP implementations have similar design factors that limit their performance with large backlogs, and there seems to be no compelling reason why stacks should be re-engineered to support extremely large backlogs, since other solutions are available. However, experiments with large backlogs using efficient data structures and search algorithms have not been conducted, to our knowledge.
エンドホストが大きなバックログを使用するための防衛で明らか試みがあります。レモンは、バックログのサイズは[Lem02]成長に合わせてのFreeBSD 4.4で、この戦術は、いくつかの深刻な負の側面を持っていることが示されています。実装は、数百の過去のバックログを拡張できるように設計されていない、そしてそれが使用するデータ構造と検索アルゴリズムは、より大きなバックログで非効率的です。他のTCP実装は、大きなバックログとそのパフォーマンスを制限する同様の設計因子を持っていると仮定することは合理的である、およびスタックは、他のソリューションが利用可能なので、非常に大きなバックログをサポートするために再設計されなければならない理由は何の説得力のある理由はなさそうです。しかし、大規模な効率的なデータ構造を使用してバックログや検索アルゴリズムを用いた実験は、我々の知る限り、行われていません。
Another quickly implementable defense is shortening the timeout period between receiving a SYN and reaping the created TCB for lack of progress. Decreasing the timer that limits the lifetime of TCBs in SYN-RECEIVED is also flawed. While a shorter timer will keep bogus connection attempts from persisting for as long in the backlog, and thus free up space for legitimate connections sooner, it can prevent some fraction of legitimate connections from becoming fully established. This tactic is also ineffective because it only requires the attacker to increase the barrage frequency by a linearly proportional amount. This timer reduction is sometimes implemented as a response to crossing some threshold in the backlog occupancy, or some rate of SYN reception.
別すばやく実行可能な防衛はSYNを受信し、進歩性の欠如のために作成したTCBを享受間のタイムアウト時間を短縮されます。 SYN-RECEIVEDにTCBの寿命を制限タイマーを減少させるとも欠陥があります。短いタイマーがバックログに限り持続するから偽の接続の試みを保つため、すぐに正当な接続のための領域を解放しますが、それは完全に定着しつつから正当な接続のいくつかの割合を防ぐことができます。それだけで直線的に比例した量だけ弾幕頻度を高めるために、攻撃者が必要であるため、この戦術も有効ではありません。このタイマーの減少は、時々、バックログの占有率、またはSYNの受信一部率である閾値と交差に対する応答として実装されます。
Once the entire backlog is exhausted, some implementations allow incoming SYNs to overwrite the oldest half-open TCB entry. This works under the assumption that legitimate connections can be fully established in less time than the backlog can be filled by incoming attack SYNs. This can fail when the attacking packet rate is high and/or the backlog size is small, and is not a robust defense.
全体のバックログが使い果たされると、いくつかの実装では、着信のSYNは最も古いハーフオープンTCBのエントリを上書きすることができます。これは正当な接続が完全にバックログが入ってくる攻撃のSYNによって充填することができるよりも短い時間で確立することができるという仮定の下で動作します。攻撃パケットレートが高い場合、および/またはバックログのサイズが小さく、堅牢な守備でないとき、これは失敗する可能性があります。
The SYN cache, best described by Lemon [Lem02], is based on minimizing the amount of state that a SYN allocates, i.e., not immediately allocating a full TCB. The full state allocation is delayed until the connection has been fully established. Hosts implementing a SYN cache have some secret bits that they select from the incoming SYN segments. The secret bits are hashed along with the IP addresses and TCP ports of a segment, and the hash value determines the location in a global hash table where the incomplete TCB is stored. There is a bucket limit for each hash value, and when this limit is reached, the oldest entry is dropped.
最良レモン[Lem02]によって記載SYNキャッシュは、、すなわち、すぐに完全なTCBを割り当てない、SYNを割り当てた状態の量を最小限に基づいています。接続が完全に確立されるまで、完全な状態の割り当てが遅れています。 SYNキャッシュを実装するホストは、彼らが入ってくるSYNセグメントから選択するいくつかの秘密のビットを持っています。秘密ビットがセグメントのIPアドレスとTCPポートと一緒にハッシュされ、ハッシュ値は、不完全なTCBが格納されているグローバル・ハッシュ・テーブル内の位置を決定します。そこ各ハッシュ値のためのバケット限界があり、この制限に達したとき、最も古いエントリは削除されます。
The SYN cache technique is effective because the secret bits prevent an attacker from being able to target specific hash values for overflowing the bucket limit, and it bounds both the CPU time and memory requirements. Lemon's evaluation of the SYN cache shows that even under conditions where a SYN flooding attack is not being performed, due to the modified processing path, connection establishment is slightly more expedient. Under active attack, SYN cache performance was observed to approximately linearly shift the distribution of times to establish legitimate connections to about 15% longer than when not under attack [Lem02].
秘密ビットがバケット制限をオーバーフローするための特定のハッシュ値をターゲティングすることができるから、攻撃者を防ぐため、SYNキャッシュ技術が有効であり、それはCPU時間とメモリ要件の両方を境界。 SYNキャッシュのレモンの評価も、SYNフラッディング攻撃が原因変性処理経路に、行われていない条件下で、接続の確立がわずかにより好都合であることを示しています。アクティブな攻撃を受けて、SYNキャッシュのパフォーマンスはほぼ直線よりも長い約15％に正当な接続を確立するために時間の分布をシフトすることが観察されたときではない攻撃を受けて[Lem02]。
If data accompanies the SYN segment, then this data is not acknowledged or stored by the receiver, and will require retransmission. This does not affect the reliability of TCP's data transfer service, but it does affect its performance to some small extent. SYNs carrying data are used by the T/TCP extensions [RFC1644]. While T/TCP is implemented in a number of popular operating systems [GN00], it currently seems to be rarely used. Measurements at one site's border router [All07] logged 2,545,785 SYN segments (not SYN-ACKs), of which 36 carried the T/TCP CCNEW option (or 0.001%). These came from 26 unique hosts, and no other T/TCP options were seen. 2,287 SYN segments with data were seen (or 0.09% of all SYN segments), all of which had exactly 24 bytes of data. These observations indicate that issues with SYN caches and data on SYN segments may not be significant in deployment.
データはSYNセグメントを伴う場合、このデータは、肯定応答または受信機によって記憶され、再送が必要になりません。これは、TCPのデータ転送サービスの信頼性に影響を与えませんが、それはいくつかの小さな範囲でその性能に影響を与えません。データを運ぶのSYNは、T / TCP拡張[RFC1644]で使用されます。 T / TCPは、一般的なオペレーティングシステム[GN00]の数で実装されているが、現在ほとんど使用されないことのようです。一つのサイトの境界ルータ[All07]での測定36はT / TCP CCNEWオプション（または0.001％）を実施その2545785個のSYNセグメント（ないSYN-ACKを）、ログイン。これらは、26台のユニークなホストから来て、他のT / TCPオプションは見られませんでした。データの正確に24バイトを持っていたすべてがデータを見られたと2,287 SYNセグメント（またはすべてのSYNセグメントの0.09％）。これらの観察は、SYNセグメント上のSYNキャッシュとデータに問題が展開で重要ではないかもしれないことを示しています。
SYN cookies go a step further and allocate no state at all for connections in SYN-RECEIVED. Instead, they encode most of the state (and all of the strictly required) state that they would normally keep into the sequence number transmitted on the SYN-ACK. If the SYN was not spoofed, then the acknowledgement number (along with several other fields) in the ACK that completes the handshake can be used to reconstruct the state to be put into the TCB. To date, one of the best references on SYN cookies can be found on Dan Bernstein's web site [cr.yp.to]. This technique exploits the long-understood low entropy in TCP header fields [RFC1144][RFC4413]. In Appendix A, we describe the SYN cookie technique, to avoid the possibility that the web page will become unavailable.
SYNクッキーは、さらに一歩進み、SYN-RECEIVED内の接続のためにまったく状態を割り当てません。代わりに、彼らは通常、SYN-ACKに送信されたシーケンス番号に保つだろうと状態（厳密に必要なのと、すべての）状態のほとんどをコードします。 SYNがスプーフィングされなかった場合は、ハンドシェイクを完了ACKで（いくつかの他のフィールドと一緒に）確認番号は、TCBに入れなければ状態を再構築するために使用することができます。現在までに、SYNクッキーで最高の参照の一つはダン・バーンスタインのウェブサイト[cr.yp.to]で見つけることができます。この技術は、TCPヘッダーフィールド[RFC1144]、[RFC4413]に長い理解低いエントロピーを利用します。付録Aでは、我々は、Webページが利用できなくなる可能性を避けるために、SYNクッキーの技術を説明します。
The exact mechanism for encoding state into the SYN-ACK sequence number can be implementation dependent. A common consideration is that to prevent replay, some time-dependent random bits must be embedded in the sequence number. One technique used 7 bits for these bits and 25 bits for the other data [Lem02]. One way to encode these bits has been to XOR the initial sequence number received with a truncated cryptographic hash of the IP address and TCP port number pairs, and secret bits. In practice, this hash has been generated using MD5 [RFC1321]. Any similar one-way hash could be used instead without impacting interoperability since the hash value is checked by the same host who generates it.
SYN-ACKシーケンス番号に状態を符号化するための正確な機構は実装依存とすることができます。一般的な考慮事項は、いくつかの時間依存ランダムビットシーケンス番号に埋め込まれなければならない、リプレイを防止することです。一つの技術は、これらのビットのために7ビット、および他のデータ[Lem02]、25ビットを使用します。これらのビットを符号化する一つの方法は、IPアドレスとTCPポート番号のペアの切断された暗号化ハッシュを受信した初期シーケンス番号、および秘密のビットをXORすることでした。実際には、このハッシュは、MD5 [RFC1321]を使用して生成されています。ハッシュ値は、それを生成し、同じホストによって確認されているので、任意の同様の一方向ハッシュは、相互運用性に影響を与えることなく、代わりに使用することができます。
The problem with SYN cookies is that commonly implemented schemes are incompatible with some TCP options, if the cookie generation scheme does not consider them. For example, an encoding of the Maximum Segment Size (MSS) advertised on the SYN has been accommodated by using 2 sequence number bits to represent 4 predefined common MSS values. Similar techniques would be required for some other TCP options, while negotiated use of other TCP options can be detected implicitly. A timestamp on the ACK, as an example, indicates that Timestamp use was successfully negotiated on the SYN and SYN-ACK, while the reception of a Selective Acknowledgement (SACK) option at some point during the connection implies that SACK was negotiated. Note that SACK blocks should normally not be sent by a host using TCP cookies unless they are first received. For the common unidirectional data flow in many TCP connections, this can be a problem, as it limits SACK usage. For this reason, SYN cookies typically are not used by default on systems that implement them, and are only enabled either under high-stress conditions indicative of an attack, or via administrative action.
SYNクッキーの問題は、クッキー生成方式は、それらを考慮していない場合、一般的に実装スキームは、いくつかのTCPオプションと互換性がないということです。例えば、SYNで宣伝最大セグメントサイズ（MSS）の符号化は、4つの事前定義された一般的なMSS値を表すために2シーケンス番号のビットを使用して収容されています。他のTCPオプションの交渉され使用が暗黙的に検出することができながら、同様の技術は、いくつかの他のTCPオプションのために必要とされるであろう。 ACKのタイムスタンプは、一例として、接続中のある時点で選択的確認応答（SACK）オプションの受信はSACKがネゴシエートされたことを意味している間のタイムスタンプの使用が正常に、SYNおよびSYN-ACKにネゴシエートされたことを示しています。彼らが最初に受信されない限り、そのSACKブロックは、通常、TCPのクッキーを使用して、ホストによって送信されるべきではありません注意してください。それはSACKの使用を制限して、多くのTCPコネクションに共通の単方向のデータフローでは、これは、問題になる可能性があります。このため、SYNクッキーは、一般的にそれらを実装するシステムではデフォルトで使用されていない、とだけ高ストレス条件下での攻撃を示す、または管理アクションのいずれかを介して有効になっています。
Recently, a new SYN cookie technique developed for release in FreeBSD 7.0 leverages the bits of the Timestamp option in addition to the sequence number bits for encoding state. Since the Timestamp value is echoed back in the Timestamp Echo field of the ACK packet, any state stored in the Timestamp option can be restored similarly to the way that it is from the sequence number / acknowledgement in a basic SYN cookie. Using the Timestamp bits, it is possible to explicitly store state bits for things like send and receive window scales, SACK-allowed, and TCP-MD5-enabled, for which there is no room in a typical SYN cookie. This use of Timestamps to improve the compromises inherent in SYN cookies is unique to the FreeBSD implementation, to our knowledge. A limitation is that the technique can only be used if the SYN itself contains a Timestamp option, but this option seems to be widely implemented today, and hosts that support window scaling and SACK typically support timestamps as well.
最近、FreeBSDの7.0のリリースのために開発された新しいSYNクッキー技術は状態を符号化するためのシーケンス番号ビットに加えて、タイムスタンプオプションのビットを活用します。タイムスタンプ値はバックACKパケットのタイムスタンプエコーフィールドにエコーされているので、タイムスタンプオプションに格納されている状態は、それが基本的なSYNクッキーに/確認応答シーケンス番号からのものであることを方法と同様に回復させることができます。タイムスタンプのビットを使用して、それが明示的に送信のようなものの状態ビットを格納し、ウィンドウのスケールを受信することが可能である、SACK-許可、およびTCP-MD5に対応し、一般的なSYNクッキーに空きがないいます。 SYNクッキーに固有の妥協を改善するためのタイムスタンプの使用は我々の知る限り、FreeBSDの実装に固有のものです。制限は、SYN自体はタイムスタンプオプションが含まれていますが、このオプションは、今日広く実装されているようだ、とウィンドウスケーリングとSACKをサポートするホストは、一般的にもタイムスタンプをサポートする場合の手法にのみ使用することができるということです。
Similarly to SYN caches, SYN cookies do not handle application data piggybacked on the SYN segment.
同様にSYNキャッシュに、SYNクッキーは、アプリケーションデータを処理していないSYNセグメントに便乗。
Another problem with SYN cookies is for applications where the first application data is sent by the passive host. If this host is handling a large number of connections, then packet loss may be likely. When a handshake-completing ACK from the initiator is lost, the passive side's application layer never is notified of the connection's existence and never sends data, even though the initiator thinks that the connection has been successfully established. An example application where the first application-layer data is sent by the passive side is SMTP, if implemented according to RFC 2821, where a "service ready" message is sent by the passive side after the TCP handshake is completed.
SYNクッキーのもう一つの問題は、最初のアプリケーションデータは、パッシブホストによって送信されたアプリケーションのためです。このホストが多数の接続を処理している場合、パケットロスが可能性が高いです。イニシエータからのハンドシェイクが完了ACKが失われた場合、パッシブ側のアプリケーション層は、イニシエータが、接続が正常に確立されたと考えていても、接続の存在を通知し、決してデータを送信されません。 TCPハンドシェークが完了した後、「サービス準備完了」メッセージが受動側によって送信されるRFC 2821に記載の実装場合は、最初のアプリケーション層データは、受動側によって送信される例示的なアプリケーションは、SMTPです。
Although SYN cookie implementations exist and are deployed, the use of SYN cookies is often disabled in default configurations, so it is unclear how much operational experience actually exists with them or if using them opens up new vulnerabilities. Anecdotes of incidents where SYN cookies have been used on typical web servers seem to indicate that the added processing burden of computing MD5 sums for every SYN packet received is not significant in comparison to the loss of application availability when undefended. For some computationally constrained mobile or embedded devices, this situation might be different.
SYNクッキー実装が存在し、展開されていますが、SYNクッキーの使用は、多くの場合、デフォルト設定では無効になっているので、多くの運用経験が実際に彼らと存在しているかは不明であるか、使用している場合、それらは、新たな脆弱性を開きます。 SYNクッキーは、一般的なWebサーバ上で使用された事件の逸話は、受け取ったすべてのSYNパケットのMD5サムを計算する追加処理負担が無防備アプリケーションの可用性の損失と比較して有意でないことを示しているように見えます。いくつかの計算上の制約モバイルや組み込みデバイスの場合、この状況が異なる場合があります。
The SYN cache and SYN cookie techniques can be combined. For example, in the event that the cache becomes full, then SYN cookies can be sent instead of purging cache entries upon the arrival of new SYNs. Such hybrid approaches may provide a strong combination of the positive aspects of each approach. Lemon has demonstrated the utility of this hybrid [Lem02].
SYNキャッシュとSYNクッキーの技術を組み合わせることができます。たとえば、キャッシュがいっぱいになった場合に、その後、SYNクッキーは、新しいSYNの到着時にキャッシュエントリをパージするのではなく、送信することができます。このようなハイブリッドアプローチは、各アプローチの肯定的な側面の強力な組み合わせを提供してもよいです。レモン、このハイブリッド[Lem02]の有用性を実証しました。
Firewall-based tactics may also be used to defend end hosts from SYN flooding attacks. The basic concept is to offload the connection establishment procedures onto a firewall that screens connection attempts until they are completed and then proxies them back to protected end hosts. This moves the problem away from end hosts to become the firewall's or proxy's problem, and may introduce other problems related to altering TCP's expected end-to-end semantics. A common tactic used in these firewall and proxy products is to implement one of the end host based techniques discussed above, and screen incoming SYNs from the protected network until the connection is fully established. This is accomplished by spoofing the source addresses of several packets to the initiator and listener at various stages of the handshake [Eddy06].
ファイアウォールベース戦術はまた、SYNフラッディング攻撃からエンドホストを防御するために使用することができます。基本的な考え方は、それらが完了するまで接続試行をスクリーニングして、保護されたエンドホストにそれらをバックプロキシファイアウォールに接続確立手順をオフロードすることです。これは、ファイアウォールのか、プロキシの問題になるために離れてエンドホストからの問題点を移動し、TCPの期待エンドツーエンドのセマンティクスを変更することに関連する他の問題を導入することができます。これらのファイアウォールやプロキシ製品に使用される一般的な戦術は、上述のエンドホストベースの技術のいずれかを実装し、接続が完全に確立されるまで、保護されたネットワークからの着信のSYNをスクリーニングすることです。これは、ハンドシェイク[Eddy06]の様々な段階におけるイニシエータとリスナーにいくつかのパケットの送信元アドレスを偽装することによって達成されます。
Several of the defenses discussed in the previous section rely on changes to behavior inside the network; via router filtering, firewalls, and proxies. These may be highly effective, and often require no modification or configuration of end-host software. Given the mobile nature and dynamic connectivity of many end hosts, it is optimistic for TCP implementers to assume the presence of such protective devices. TCP implementers should provide some means of defense to SYN flooding attacks in end-host implementations.
前のセクションで説明した防御のいくつかは、ネットワーク内の行動の変化に依存しています。ルータのフィルタリング、ファイアウォール、プロキシを経由して。これらは、非常に効果的であること、そして多くの場合、エンド・ホスト・ソフトウェアの修正や設定を必要としないことがあります。 TCPの実装は、このような保護装置の存在を前提とするために、モバイル自然と多くのエンドホストの動的な接続性を考えると、それは楽観的です。 TCPの実装は、エンドホストの実装でSYNフラッド攻撃への防御手段を提供する必要があります。
Among end-host modifications, the SYN cache and SYN cookie approaches seem to be the only viable techniques discovered to date. Increasing the backlog and reducing the SYN-RECEIVED timer are measurably problematic. The SYN cache implies a higher memory footprint than SYN cookies; however, SYN cookies may not be fully compatible with some TCP options, and may hamper development of future TCP extensions that require state. For these reasons, SYN cookies should not be enabled by default on systems that provide them. SYN caches do not have the same negative implications and may be enabled as a default mode of processing.
エンドホストの変更の中で、SYNキャッシュとSYNクッキーのアプローチは、現在までに発見された唯一の実行可能な技術であるように見えます。バックログを増やすとSYN-RECEIVEDタイマーを低減することが測定できる問題です。 SYNキャッシュは、SYNクッキーよりも高いメモリフットプリントを意味します。しかし、SYNクッキーは、いくつかのTCPオプションと完全に互換性がない可能性があり、および状態を必要とする将来のTCP拡張の開発を妨げる可能性があります。これらの理由から、SYNクッキーは、それらを提供するシステムではデフォルトで有効にすべきではありません。 SYNキャッシュは同じ負の意味合いを持っていないと処理のデフォルトモードとして有効にすることができます。
In October of 1996, Dave Borman implemented a SYN cache at BSDi for BSD/OS, which was given to the community with no restrictions. This code seems to be the basis for the SYN cache implementations adopted later in other BSD variants. The cache was used when the backlog became full, rather than by default, as we have described. A note to the tcp-impl mailing list explains that this code does not retransmit SYN-ACKs [B97]. More recent implementations have chosen to reverse this decision and retransmit SYN-ACKs. It is known that loss of SYN-ACK packets is not uncommon [SD01] and can severely slow the performance of connections when initial retransmission timers for SYNs are overly conservative (as in some operating systems) or retransmitted SYNs are lost. Furthermore, if a SYN flooding attacker has a high sending rate, loss of retransmitted SYNs is likely, so if SYN-ACKs are not retransmitted, the chance of efficiently establishing legitimate connections is reduced.
1996年の10月に、デイブ・ボーマンは制限なしで社会に与えたBSD / OS、ためにBSDIでSYNキャッシュを実装しました。このコードは、他のBSDの変種で、後に採用されたSYNキャッシュ実装の基盤であると思われます。バックログがいっぱいになったときに我々が説明したようキャッシュは、むしろデフォルトでより、使用されました。 TCP-のimplメーリングリストへのノートでは、このコードでは、SYN-ACKの[B97]を再送しないことを説明しています。より最近の実装は、この決定を覆すとSYN-ACKを再送信することを選択しました。 SYN-ACKパケットの損失は珍しい[SD01]はないとのSYNの初期再送タイマが（いくつかのオペレーティングシステムのように）過度に保守的であるか、または再送のSYNが失われた場合に深刻な接続のパフォーマンスが低下することが知られています。さらに、SYNフラッド攻撃者は、高い送信レートを持っている場合は、再送されたSYNの損失がありそうなので、SYN-ACKが再送されていない場合は、効率的に確立する正当な接続の機会が減少しています。
In 1997, NetBSD incorporated a modified version of Borman's code. Two notable differences from the original code stem from the decision to use the cache by default (for all connections). This implied the need to perform retransmissions for SYN-ACKs, and to use larger structures to keep more complete data. The original structure was 32 bytes long for IPv4 connections and 56 bytes with IPv6 support, while the current FreeBSD structure is 196 bytes long. As previously cited, Lemon implemented the SYN cache and cookie techniques in FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up 160 bytes compared to 736 for the full TCB (now 196 bytes for the cache structure). We have examined the OpenBSD 3.6 code and determined that it includes a similar SYN cache.
1997年に、NetBSDはボーマンのコードの修正版を組み込みました。元のコードからの二つの顕著な違いは、（すべての接続用）、デフォルトでキャッシュを使用するという決定から生じます。これは、SYN-ACKのために再送信を実行するために、そしてより完全なデータを保持するために、より大きな構造を使用する必要性を暗示しました。現在のFreeBSDの構造は196バイト長である元の構造は、IPv6をサポートしたIPv4接続と56バイト、32バイト長でした。先に引用したように、レモンは、FreeBSD 4.4 [Lem02]でSYNキャッシュとクッキー技術を実装しました。レモンは、SYNキャッシュ構造は完全なTCB（キャッシュ構造のため、今196バイト）のための736に比べて160のバイトを始めたことを指摘しています。我々は、OpenBSD 3.6コードを検査し、それが同様のSYNキャッシュを含むことを決定しました。
Linux 2.6.5 code, also by examination, contains a SYN cookie implementation that encodes 8 MSS values, and does not use SYN cookies by default. This functionality has been present in the Linux kernel for several years previous to 2.6.5.
Linuxの2.6.5のコードは、また検査によって、8つのMSS値を符号化し、デフォルトでSYNクッキーを使用していないSYNクッキーの実装が含まれています。この機能は、2.6.5より前の数年間、Linuxカーネルに存在しています。
When a SYN cache and/or SYN cookies are implemented with IPv6, the IPv6 flow label value used on the SYN-ACK should be consistent with the flow label used for the rest of the packets within that flow. There have been implementation bugs that caused random flow labels to be used in SYN-ACKs generated by SYN cache and SYN cookie code [MM05].
SYNキャッシュおよび/またはSYNクッキーがIPv6で実装されている場合、SYN-ACKで使用されるのIPv6フローラベルの値は、そのフロー内のパケットの残りの部分に使用するフローラベルと一致する必要があります。 [MM05] SYNキャッシュとSYNクッキーのコードによって生成されたSYN-ACKの中で使用されるランダムなフローラベルを引き起こした実装のバグがありました。
Beginning with Windows 2000, Microsoft's Windows operating systems have had a "TCP SYN attack protection" feature, which can be toggled on or off in the registry. This defaulted to off, until Windows 2003 SP1, in which it is on by default. With this feature enabled, when the number of half-open connections and half-open connections with retransmitted SYN-ACKs exceeds configurable thresholds, then the number of times that SYN-ACKs are retransmitted before giving up is reduced, and the "Route Cache Entry" creation is delayed, which prevents some features (e.g., window scaling) from being used [win2k3-wp].
Windows 2000の以降では、MicrosoftのWindowsオペレーティングシステムは、レジストリ内のオンまたはオフを切り替えることができる「TCP SYN攻撃に対する保護」機能を、持っていました。これは、デフォルトでオンになっているのWindows 2003 SP1、までは、オフにデフォルト設定しました。この機能を使用すると、ハーフオープン接続再送SYN-ACKを持つハーフオープン接続数が設定可能なしきい値を超えた場合に、SYN-ACKのをあきらめる前に再送信されている回数の後、数が減少し、「ルートキャッシュエントリ、有効「作成は、[WIN2K3-WP]使用されているから、いくつかの機能（例えば、ウィンドウスケーリング）を防止する、遅延しています。
Several vendors of commercial firewall products sell devices that can mitigate SYN flooding's effects on end hosts by proxying connections.
商用ファイアウォール製品のいくつかのベンダーは接続をプロキシすることにより、エンドホスト上のSYNフラッドの影響を軽減することができる装置を販売しています。
Discovery and exploitation of the SYN flooding vulnerability in TCP's design provided a valuable lesson for protocol designers. The Stream Control Transmission Protocol [RFC2960], which was designed more recently, incorporated a 4-way handshake with a stateless cookie-based component for the listening end. In this way, the passive-opening side has better evidence that the initiator really exists at the given address before it allocates any state. The Host Identity Protocol base exchange [MNJH07] is similarly designed as a 4-way handshake, but also involves a puzzle sent to the initiator that must be solved before any state is reserved by the responder. The general concept of designing statelessness into protocol setup to avoid denial-of-service attacks has been discussed by Aura and Nikander [AN97].
TCPのデザインのSYNフラッドの脆弱性の発見と搾取は、プロトコル設計者のための貴重なレッスンを提供しました。より最近に設計されたストリーム制御伝送プロトコル[RFC2960]は、リスニング・エンドのステートレスクッキーベースのコンポーネントで4ウェイハンドシェイクを組み込みました。このように、受動開口側は、それがどのような状態を割り振る前に、イニシエータが本当に指定されたアドレスに存在することを、より良い証拠を持っています。ホストアイデンティティプロトコルベースの交換[MNJH07】も同様に4ウェイハンドシェイクのように設計されるが、任意の状態がレスポンダによって予約される前に解決されなければならないイニシエータに送信されたパズルを含みます。サービス拒否攻撃を回避するためのプロトコルのセットアップにステートレスを設計する一般的な概念は、オーラとNikander [AN97]で議論されています。
The SYN flooding attack on TCP has been described in numerous other publications, and the details and code needed to perform the attack have been easily available for years. Describing the attack in this document does not pose any danger of further publicizing this weakness in unmodified TCP stacks. Several widely deployed operating systems implement the mitigation techniques that this document discusses for defeating SYN flooding attacks. In at least some cases, these operating systems do not enable these countermeasures by default; however, the mechanisms for defeating SYN flooding are well deployed, and easily enabled by end-users. The publication of this document should not influence the number of SYN flooding attacks observed, and might increase the robustness of the Internet to such attacks by encouraging use of the commonly available mitigations.
TCPのSYNフラッド攻撃は、多数の他の刊行物に記載されており、攻撃を実行するために必要な詳細情報と、コードは何年も簡単に利用されてきました。このドキュメントで攻撃を記述すること、さらに未変更のTCPスタックでこの弱点を公表するあらゆる危険をもたらすことはありません。いくつかの広く展開されているオペレーティングシステムでは、この文書は、SYNフラッド攻撃を倒すために議論緩和技術を実装しています。少なくともいくつかのケースでは、これらのオペレーティングシステムは、デフォルトでは、これらの対策を有効にしません。しかし、SYNフラッディングを倒すためのメカニズムは十分に展開され、容易にエンドユーザによって使用可能。本書の出版物は観察されSYNフラッド攻撃の数に影響を与えてはならない、と一般的に利用可能な緩和策の使用を奨励することにより、このような攻撃にインターネットの堅牢性を高める可能性があります。
A conversation with Ted Faber was the impetus for writing this document. Comments and suggestions from Joe Touch, Dave Borman, Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, Mark Allman, Lars Eggert, Pasi Eronen, Warren Kumari, David Malone, Ron Bonica, and Lisa Dusseault were useful in strengthening this document. The original work on TCP SYN cookies presented in Appendix A is due to D.J. Bernstein.
テッド・フェイバーとの会話には、この文書を書くための原動力でした。ジョー・タッチ、デイブ・ボーマン、フェルナンドGont、ジャン=バティスト・マルシャン、クリスチャンのHuitema、ケイトリンBestler、ペッカSavola、アンドレOppermannの、アルフレッドHoenes、マーク・オールマン、ラースEggertの、パシEronen、ウォーレン・クマリ、デビッド・マローン、ロンBonicaからのコメントや提案、そしてリサDusseaultはこの文書を強化する上で有用でした。付録Aに提示TCP SYNクッキーのオリジナル作品は、D.J.によるものですバーンスタイン。
Work on this document was performed at NASA's Glenn Research Center. Funding was partially provided by a combination of NASA's Advanced Communications, Navigation, and Surveillance Architectures and System Technologies (ACAST) project, the Sensis Corporation, NASA's Space Communications Architecture Working Group, and NASA's Earth Science Technology Office.
このドキュメントの作業はNASAのグレンリサーチセンターで行われました。資金の一部はNASAの高度な通信、ナビゲーション、および監視アーキテクチャとシステムテクノロジー（ACAST）プロジェクト、Sensis社（株）、NASAの宇宙通信アーキテクチャワーキンググループ、およびNASAの地球科学技術局の組み合わせによって提供されました。
[AN97] Aura, T. and P. Nikander, "Stateless Connections", Proceedings of the First International Conference on Information and Communication Security, 1997.
[AN97]オーラ、T.およびP. Nikander、「ステートレス接続」、情報通信セキュリティ、1997年第一回国際会議の議事録。
[All07] Allman, M., "personal communication", February 2007.
[All07]オールマン、M.、 "個人的なコミュニケーション"、2007年2月。
[B96] Bennahum, D., "PANIX ATTACK", MEME 2.12, October 1996, <http://memex.org/meme2-12.html>.
[B96] Bennahum、D.、 "PANIX ATTACK"、MEME 2.12、1996年10月、<http://memex.org/meme2-12.html>。
[B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick clarification...)", IETF tcp-impl mailing list, June 1997.
[B97]ボーマン、D.、 "再：SYN / RSTクッキーを（再れました：速い明確化...）"、IETF TCP-のimplメーリングリスト、1997年6月を。
[CA-96.21] CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks", September 1996.
[CA-96.21] CERT、 "CERT勧告CA-1996から1921 TCP SYNフラッドとIPスプーフィング攻撃"、1996年9月。
[CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet Security", ISBN: 0201633574, January 1994.
[CB94]チェスウィック、W.とS. Bellovin氏、 "ファイアウォールとインターネットセキュリティ"、ISBN：0201633574、1994年1月。
[Eddy06] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", Cisco Internet Protocol Journal Volume 8, Number 4, December 2006.
[Eddy06]エディ、W.、シスコのインターネットプロトコルジャーナルボリューム8、ナンバー4 "TCP SYNフラッド攻撃に対する防御"、2006年12月。
[GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions", Linux Journal, February 2000.
[GN00]グリフィン、M.とJ.ネルソン、 "T / TCP：取引のためのTCP"、Linuxのジャーナル、2000年2月。
[Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN Cache", BSDCON 2002, February 2002.
[Lem02]レモン、J.、BSDCON 2002、2002年2月 "SYNキャッシュとSYNフラッドDoS攻撃に抵抗します"。
[MM05] McGann, O. and D. Malone, "Flow Label Filtering Feasibility", European Conference on Computer Network Defense 2005, December 2005.
[MM05] McGann、O.およびD.マローン、「フローラベルフィルタリングの実現可能性」、コンピュータネットワーク防衛2005、2005年12月に欧州会議。
[MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Work in Progress, June 2007.
[MNJH07]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、進歩、2007年6月に作業。
[P48-13] daemon9, route, and infinity, "Project Neptune", Phrack Magazine, Volume 7, Issue 48, File 13 of 18, July 1996.
[P48-13] daemon9、ルート、および無限大、 "プロジェクト・ネプチューン"、Phrack誌、第7巻、号48、18の13ファイル、1996年7月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、RFC 1144、1990年2月 "低速シリアルリンク用のTCP / IPヘッダの圧縮"。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、B.、 "T / TCP - 取引機能仕様のためのTCP拡張機能"、RFC 1644、1994年7月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013] Killalea、T.、 "推奨インターネットサービスプロバイダのセキュリティサービスと手続き"、BCP 46、RFC 3013、2000年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006.
[RFC4413]西、M.とS.マッキャン、 "TCP / IPフィールドの動作"、RFC 4413、2006年3月。
[SD01] Seddigh, N. and M. Devetsikiotis, "Studies of TCP's Retransmission Timeout Mechanism", Proceedings of the 2001 IEEE International Conference on Communications (ICC 2001), volume 6, pages 1834-1840, June 2001.
[SD01] Seddigh、N.およびM. Devetsikiotis、2001年IEEE国際会議の議事録 "TCPの再送タイムアウトメカニズムの研究" コミュニケーション上の（ICC 2001）、第6巻、頁1834年から1840年、2001年6月。
[SKK+97] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, A., and D. Zamboni, "Analysis of a Denial of Service Attack on TCP", Proceedings of the 1997 IEEE Symposium on Security and Privacy 1997.
[SKK + 97] Schuba、C.、Krsul、I.、クーン、M.、SPAFFORD、E.、Sundaram、A.、およびD.ザンボーニ、 "TCP上のサービス拒否攻撃の分析"、議事録1997 IEEEシンポジウムセキュリティとプライバシー1997年。
[Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume 2: The Implementation", January 1995.
[Ste95]スティーブンス、W。およびG.ライト、 "TCP / IPイラスト、2巻：インプリメンテーション"、1995年1月。
[cr.yp.to] Bernstein, D., "SYN cookies", visited in December 2005, <http://cr.yp.to/syncookies.html>.
[cr.yp.to]バーンスタイン、D.、 "SYNクッキー" は、2005年12月に訪問し、<http://cr.yp.to/syncookies.html>。
[win2k3-wp] Microsoft Corporation, "Microsoft Windows Server 2003 TCP/IP Implementation Details", White Paper, July 2005.
[WIN2K3-WP]マイクロソフトコーポレーション、 "マイクロソフトのWindows Server 2003のTCP / IP実装の詳細"、ホワイトペーパー、2005年7月。
Appendix A. SYN Cookies Description
付録A. SYNクッキー説明
This information is taken from Bernstein's web page on SYN cookies [cr.yp.to]. This is a rewriting of the technical information on that web page and not a full replacement. There are other slightly different ways of implementing the SYN cookie concept than the exact means described here, although the basic idea of encoding data into the SYN-ACK sequence number is constant.
この情報は、SYNクッキー[cr.yp.to]でバーンスタインのWebページから取得されます。これは、Webページ上の技術的な情報の書き換えではなく、完全な代替品です。 SYN-ACKシーケンス番号にデータを符号化の基本的な考え方は一定であるが、正確な手段は、ここで説明するよりも、SYNクッキーのコンセプトを実現するための他のわずかに異なる方法があります。
A SYN cookie is an initial sequence number sent in the SYN-ACK, that is chosen based on the connection initiator's initial sequence number, MSS, a time counter, and the relevant addresses and port numbers. The actual bits comprising the SYN cookie are chosen to be the bitwise difference (exclusive-or) between the SYN's sequence number and a 32 bit quantity computed so that the top five bits come from a 32-bit counter value modulo 32, where the counter increases every 64 seconds, the next 3 bits encode a usable MSS near to the one in the SYN, and the bottom 24 bits are a server-selected secret function of pair of IP addresses, the pair of port numbers, and the 32-bit counter used for the first 5 bits. This means of selecting an initial sequence number for use in the SYN-ACK complies with the rule that TCP sequence numbers increase slowly.
SYNクッキーは、接続開始の初期シーケンス番号、MSS、時間カウンタ、および関連するアドレスとポート番号に基づいて選択されたSYN-ACKで送信された初期シーケンス番号です。 SYNクッキーを含む実際のビットはSYNのシーケンス番号と上位5ビットは32ビットカウンタ値モジュロ32から来るように計算された32ビット量、カウンタ間（排他的論理和）ビット単位の差であるように選択されます毎64秒に増加し、次の3ビットはSYNに1に近い使用可能なMSSをコードし、そしてボトム24ビットIPアドレスのペアのサーバ選択秘密機能、ポート番号の対、及び32ビットであります最初の5ビットに使用されるカウンタ。これは、SYN-ACKで使用するための初期シーケンス番号を選択する手段TCPシーケンス番号が徐々に増加することをルールに準拠しています。
When a connection in LISTEN receives a SYN segment, it can generate a SYN cookie and send it in the sequence number of a SYN-ACK, without allocating any other state. If an ACK comes back, the difference between the acknowledged sequence number and the sequence number of the ACK segment can be checked against recent values of the counter and the secret function's output given those counter values and the IP addresses and port numbers in the ACK segment. If there is a match, the connection can be accepted, since it is statistically very likely that the other side received the SYN cookie and did not simply guess a valid cookie value. If there is not a match, the connection can be rejected under the heuristic that it is probably not in response to a recently sent SYN-ACK.
LISTENで接続がSYNセグメントを受信すると、SYNクッキーを生成することができる、任意の他の状態を割り当てずに、SYN-ACKのシーケンス番号にそれを送ります。 ACKが戻ってきた場合は、認めシーケンス番号とACKセグメントのシーケンス番号との違いは、ACKセグメントでこれらのカウンタ値とIPアドレスとポート番号を与えられた最近のカウンタの値と秘密の関数の出力に対してチェックすることができます。一致するものがあれば、統計的に相手側がSYNクッキーを受信し、単に有効なクッキーの値を推測しなかったことは非常に可能性があるため、接続は、受け入れることができます。一致しない場合、接続はそれが最近送られたSYN-ACKに応じて、おそらくないヒューリスティックの下で拒否することができます。
With SYN cookies enabled, a host will be able to remain responsive even when under a SYN flooding attack. The largest price to be paid for using SYN cookies is in the disabling of the window scaling option, which disables high performance.
SYNクッキーを有効にすると、ホストは、SYNフラッド攻撃を受けた場合にも反応するままにすることができるようになります。 SYNクッキーを使用するために支払われる最大の価格が高いパフォーマンスを無効にウィンドウスケーリングオプションの無効です。
Bernstein's web page [cr.yp.to] contains more information about the initial conceptualization and implementation of SYN cookies, and archives of emails documenting this history. It also lists some false negative claims that have been made about SYN cookies, and discusses reducing the vulnerability of SYN cookie implementations to blind connection forgery by an attacker guessing valid cookies.
バーンスタインのWebページには、[cr.yp.to]初期概念とSYNクッキーの実装、およびこの歴史を文書化した電子メールのアーカイブに関する詳細情報が含まれています。また、SYNクッキーについて行われてきたいくつかの偽陰性の主張を一覧表示し、有効なクッキーを推測する攻撃者によって接続偽造をブラインドSYNクッキー実装の脆弱性を減らすことについて説明します。
The best description of the exact SYN cookie algorithms is in a part of an email from Bernstein, that is archived on the web site (notice it does not set the top five bits from the counter modulo 32, as the previous description did, but instead uses 29 bits from the second MD5 operation and 3 bits for the index into the MSS table; establishing the secret values is also not discussed). The remainder of this section is excerpted from Bernstein's email [cr.yp.to]:
正確なSYNクッキーアルゴリズムの最良の説明はバーンスタインからの電子メールの一部であり、ウェブサイト上でアーカイブされている（以前の記述が行ったように、それは、カウンタ・モジュロ32から上位5ビットを設定しません気付き、代わりにMSSテーブルに第MD5動作から29ビットとインデックスの3ビットを使用し、また、議論されていない秘密の値を確立します）。このセクションの残りの部分は、バーンスタインの電子メール[cr.yp.to]から抜粋されています。
Here's what an implementation would involve:
ここでは実装が伴うだろう何：
Maintain two (constant) secret keys, sec1 and sec2.
SEC1及びSEC2 2（定数）秘密鍵を、維持します。
Maintain a (constant) sorted table of 8 common MSS values, msstab[8].
8つの一般的なMSS値（定数）ソートされたテーブルを維持し、msstab [8]。
Keep track of a "last overflow time".
「最後のオーバフロー時間」を追跡します。
Maintain a counter that increases slowly over time and never repeats, such as "number of seconds since 1970, shifted right 6 bits".
など、時間をかけてゆっくりと増加し、繰り返されることはありませんカウンタを維持し、「1970年からの秒数、右に6ビットシフト」。
When a SYN comes in from (saddr,sport) to (daddr,dport) with ISN x, find the largest i for which msstab[i] <= the incoming MSS. Compute
SYNがISN xと共に（DADDR、DPORT）に（SADDR、スポーツ）から入ってくるときに、私はこれのために[i]は<=着信MSSをmsstab最大見つけます。計算
z = MD5(sec1,saddr,sport,daddr,dport,sec1)
Z = MD5（SEC1、SADDR、スポーツ、DADDR、DPORT、SEC1）
+ x
+ X
+ (counter << 24)
+（カウンタ<< 24）
+ (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 << 24))
+（MD5（SEC2、カウンタ、SADDR、スポーツ、DADDR、DPORT、SEC2）％（1 << 24））
and then
その後
y = (i << 29) + (z % (1 << 29))
Y =（I << 29）+（（1 << 29）の％）
Create a TCB as usual, with y as our ISN. Send back a SYNACK.
私たちのISNとしてyは、いつものようにTCBを作成します。 SYNACKを送り返します。
Exception: _If_ we're out of memory for TCBs, set the "last overflow time" to the current time. Send the SYNACK anyway, with all fancy options turned off.
例外：_If_我々は現在の時間に「最後のオーバフロー時間」を設定し、のTCBのためのメモリが不足しています。すべての空想のオプションをオフにして、とにかくSYNACKを送信します。
When an ACK comes back, follow this procedure to find a TCB: (1) Look for a (saddr,sport,daddr,dport) TCB. If it's there, done.
ACKが戻ってきたとき、TCBを見つけるために、次の手順に従います。（1）（SADDR、スポーツ、DADDR、DPORT）TCBを探してください。それがあれば、完了です。
(2) If the "last overflow time" is earlier than a few minutes ago, give up.
（2）「最後のオーバフロー時間は」数分前より前の場合、あきらめます。
(3) Figure out whether our alleged ISN makes sense. This means recomputing y as above, for each of the counters that could have been used in the last few minutes (say, the last four counters), and seeing whether any of the y's match the ISN in the bottom 29 bits. If none of them do, give up.
（3）私たちの主張されたISNが理にかなっているかどうかを把握します。これは、最後の数分（たとえば、最後の4つのカウンタ）で使用されている可能性がカウンタごとに、上記のようにYを再計算し、下の29ビットにYの試合のいずれかISNを見て意味します。それらのどれもがそうしない場合は、あきらめます。
(4) Create a new TCB. The top three bits of our ISN give a usable MSS. Turn off all fancy options.
（4）新しいTCBを作成します。私たちのISNの上位3ビットが使用可能なMSSを与えます。すべての空想のオプションをオフにします。
Author's Address
著者のアドレス
Wesley M. Eddy Verizon Federal Network Systems NASA Glenn Research Center 21000 Brookpark Rd, MS 54-5 Cleveland, OH 44135
ウェズリーM.エディベライゾン連邦ネットワークシステムNASAグレンリサーチセンター21000ブルックパークRdを、MS 54-5クリーブランド、オハイオ州44135
Phone: 216-433-6682 EMail: weddy@grc.nasa.gov
電話：216-433-6682 Eメール：weddy@grc.nasa.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。