この文書はRFC 4987の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                            W. Eddy
Request for Comments: 4987                                       Verizon
Category: Informational                                      August 2007


            TCP SYN Flooding Attacks and Common Mitigations
            TCP SYN氾濫攻撃と一般的な緩和策

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).

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
   1.  はじめに
   2.  Attack Description
   2.  攻撃記述
     2.1.  History
     2.1.  歴史
     2.2.  Theory of Operation
     2.2.  動作理論
   3.  Common Defenses
   3.  一般的防御法
     3.1.  Filtering
     3.1.  フィルタリング
     3.2.  Increasing Backlog
     3.2. バックログの増加
     3.3.  Reducing SYN-RECEIVED Timer
     3.3.  SYN受信タイマの減少
     3.4.  Recycling the Oldest Half-Open TCB
     3.4.  最古の半開きTCBを再利用
     3.5.  SYN Cache
     3.5.  SYNキャッシュ
     3.6.  SYN Cookies
     3.6.  SYNクッキー
     3.7.  Hybrid Approaches
     3.7.  組合せ手法
     3.8.  Firewalls and Proxies
     3.8.  ファイアウォールとプロキシ
   4.  Analysis
   4.  分析
   5.  Security Considerations
   5.  セキュリティ問題
   6.  Acknowledgements
   6.  謝辞
   7.  Informative References
   7.  有益な参考文献
   Appendix A.  SYN Cookies Description
   付録A. SYNクッキーの記述

1.  Introduction
1.  はじめに

   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サーバ処理を実行するホストに影響するサービス妨
   害手段です。攻撃は、ポートにSYNセグメントを受信した後に、TCPが
   LISTEN状態に入りしばらく状態を維持する事を利用します。基本的な考え
   方はホストが多数の偽の半接続を持つことで、正しい接続を確立するため
   の資源を残さないようにすることです。

   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章で説明されます。
   これらの技術の使用に関する分析と議論は4章に提示されます。SYNクッ
   キーに関する詳細は付録Aに含まれています。

2.  Attack Description
2.  攻撃記述

   This section describes both the history and the technical basis of
   the SYN flooding attack.
   この章はSYN氾濫攻撃の歴史と技術的な基礎の両方について説明します。


2.1.  History
2.1.  歴史

   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氾濫の脆弱性は1994年にはBill CheswickとSteve Bellovin[B96]
   によって発見されました。彼らが本"Firewalls and Internet Security:
   Repelling the Wily Hacker" [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.
   1996年に最初に、Phrack雑誌[P48-13]の説明と開発ツールのリリースと共
   に、SYN氾濫攻撃は発生しました。いくつかの小さい誤りは別として、この
   記事は使用するのに十分高い品質があり、記事のコードは、広く配布され
   て使用されました。

   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仕様からかなり外れています。

2.2.  Theory of Operation
2.2.  動作理論

   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状態への移行を許
   可するかもしれません。ウェブサーバーのような多くの一般的なアプリケー
   ションでは、、サーバにおいて事前に詳細が未知であるクライアントと接
   続を確立できるように、リモートホストの情報が事前にわからないし、事
   前設定もされません。この種の「無制限」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実装の振舞いに依存します。
   特に、犠牲者が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 793に従って、接続がLISTEN状態にあるローカルTCPポートがSYN
   を受け取るとき、状態はSYNRECEIVEDに移行し、いくつかの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].
   例えば、リナックス2.6.10ネットワークコードでは、"sock"構造体が、TCB
   の概念を実装するのに使用されています。考察によると、この構造体をメモ
   リに保存するのに1300バイト以上必用です。それほど複雑でないTCPにアル
   ゴリズムとオプションを実装する他のシステムでは、オーバーヘッドは、よ
   り少ないかもしれませんが、通常280バイトを超えます[SKK+97]。

   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状態にだけ適用される場合もあります。一般的にシステムは、
   典型的なlisten()システムコールではバックログ(訳注:滞積している未処
   理の仕事、みたいな意味らしい )と呼ばれるパラメータを実装し、これはア
   プリケーションに値がこの限界を超えていることを示唆します。バックログ
   限界に達すると、入力の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再送を中止し、TBCが開放され
      ます。TCP仕様は任意の時間後に接続確立に見切りをつけるこの振舞い
      を含んでいません。純粋主義者の中には、人為的な制限をせずに、アプ
      リケーションがあきらめるまでTCP実装はSYNとSYN-ACKセグメント
      を再送し続ける(しかし、保守的レートの指数関数バックオフで)べき
      であると言う人もいました。にもかかわらず、今日の一般的なオペレー
      ションシステムは半開きのTCB寿命に人為的な制限をします。例えば、
      4.4 BSD-Liteでは合計511秒経過するとバックオフと停止が観測され
      [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セ
      グメントに対し、無反応であることは重要です。正常な接続ホストのア
      ドレスが使用されていると、これらのホストは犠牲者にTCPリセット
      セグメントを送って、すぐに対応するTCBが解放され正しい接続を作れ
      るバックログの余地を許すでしょう。オリジナルのPhrack記事で配布さ
      れたコードはすべての偽SYNセグメントにただ1つのソースアドレスを
      使用しました。これは攻撃セグメントを特定してフィルタにかけるのを
      いくらか簡単にします。強い攻撃者には、偽ソースアドレスを選ぶため
      に、無反応で無関係なアドレスのリストを持っているでしょう。

   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.
   実際には、攻撃者がSYN氾濫攻撃を開始するのに、偽のIPアドレスを使用
   するのではなく、多数のホストを使用するかもしれません。例えば、攻撃者
   の制御下にある感染ホストの集合(すなわち、"botnet")を使用できます。こ
   の場合、攻撃で利用された各ホストは攻撃対象から来るSYN-ACKに対するオ
   ペレーティングシステムの否定応答を抑圧しなければならないでしょう。ま
   た、攻撃TCPセグメントがここで使用した用語「弾幕」というより、連続的
   に到着する事も可能です。新しいSYNのレートがTCBを回収するレートを超
   えている限り、攻撃はうまくいくでしょう。

3.  Common Defenses
3.  一般的防御法

   This section discusses a number of defense techniques that are known
   to the community, many of which are available in off-the-shelf
   products.
   この章は、共同体で既知で、多くがすぐ入手できる製品の中に利用可能であ
   る、多くの防衛技術について論じます。

3.1.  Filtering
3.1.  フィルタリング

   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で記述されたフィルタ技術は、IP
   アドレスに基づくフィルタリングの現在の最良の実践です[RFC2827]
   [RFC3013][RFC3704]。完全に効果的であっても、フィルタのグローバルな
   配置が保証されず、またありそうでないので、終端ホストは偽セグメント
   からの攻撃を防ぐ方針をフィルタに依存すべきではありません。感染され
   たホストのグループを使用するか、または異なるアクセスプロバイダへ急
   速に移動する能力がある攻撃者はフィルタリングを無力な解決策にするで
   しょう。

3.2.  Increasing Backlog
3.2. バックログの増加

   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.
   終端ホストでの防御の明白な試みは、より大きいバックログを使用するこ
   とです。LemonはFreeBSD 4.4でこの戦術は、バックログサイズが増大する
   ことによる、いくつかの重大なマイナス面がある事を示しました[Lem02]。
   実装は数百を超えるバックログを扱うように設計されておらず、実装が使
   用しているデータ構造体と検索アルゴリズムは、巨大なバックログでは効
   率が悪くなります。他の解決策が利用可能であれば、実装が巨大なバック
   ログをサポートするように作り直される強制的な理由はないので、他のT
   CP実装でも同様に巨大なバックログで性能が制限されるような設計要因
   があると仮定するのが合理的です。しかしながら、私たちが知る限り、大
   きいバックログで効率的なデータ構造と検索アルゴリズムを使用する実験
   が行われていません。

3.3.  Reducing SYN-RECEIVED Timer
3.3.  SYN受信タイマの減少

   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を受信した後進捗のないTBCの回
   収までのタイムアウト時間を短くする事ですSYN-RECEIVED状態のTCBの寿
   命を制限するためのタイマの減少は欠点があります。より短いタイマは偽の
   接続の試みが長い時間持続するのを妨げ、その結果、正統な接続が早く可能
   になる余地を開けますが、正統の接続の一部が完全に確立するのを妨げます。
   また、攻撃者は弾幕頻度を直線的に増加すればいいいだけなので、この戦術
   は効力がありません。このタイマ減少は、バックログ占有率や、SYN受信率
   などの何らかの閾値を超えた場合の対処として時々実装されます。

3.4.  Recycling the Oldest Half-Open TCB
3.4.  最古の半開きTCBを再利用

   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がバックログ
   をいっぱいにする時間より少ない時間で、正統の接続は完全に確立できる
   という仮定の下で働きます。攻撃パケット率が高いか、バックログサイズ
   が小さい時は、仮定は誤っており、強靭な対策ではありません。

3.5.  SYN Cache
3.5.  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.
   Lemon[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].
   攻撃者が攻撃対象の特定のハッシュ値のバケツの制限をあふれさせようとす
   るのを、秘密のビットが防ぎ、ハッシュがCPU時間とメモリ条件を制限す
   るので、SYNキャッシュのテクニックは効果的です。LemonのSYNキャッシュ
   の評価は、処理パスの変更のため、SYN洪水攻撃が実行されていない場合も
   コネクション確立にわずかに好都合であることを示します。SYNキャッシュ
   性能は、活発な攻撃下での正統な接続の確立時間は、攻撃がない場合の時間
   の分布より線形にずれて、およそ15%長い事が観測されました。

   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によって使用されます[RFC1644]。T/TCPは多くの
   人気のオペレーティングシステムで実行されましたが[GN00]、現在はめった
   に使用されないように思えます。あるサイトの境界ルータでの測定の結果
   [All07]、記録された2,545,785のSYNセグメント(SYN-AAKは含まない)で、
   36セグメントがT/TCP CCNEWオプションを運び(0.001%)ました。これらは
   26台の別々のホストから来て、T/TCP以外のオプションはありませんでした。
   2,287のSYNセグメントにデータが見られ(SYNセグメント全体の0.09%)、
   この全てはちょうど24倍とのデータを持っていました。これらの観測は、
   SYNキャッシュの問題とSYNセグメントにあるデータが、実際には重要でな
   いかもしれないことを示します。

3.6.  SYN Cookies
3.6.  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に入れる状態を再構築に使用できます。Dan Bernsteinのウェブサ
   イト[cr.yp.to]でSYNクッキの最も良い参照の1つを見つけることができま
   す。このテクニックは、長く理解されている、TCPヘッダフィールドは低
   エントロピーを利用します[RFC1144][RFC4413]。ウェブページが入手できな
   くなる可能性を避けるために、付録Aで、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シーケンス番号に状態をコード化する正確なメカニズムは実装に依
   存している場合があります。一般的な考慮は、再生を防ぐために、時間依存
   する無作為の数ビットをシーケンス番号に埋め込まなければならないという
   ことです。1つのテクニックはこれにビット7ビットと、他のデータに25
   ビットを使用します。これらのビットをコード化する1つの方法は、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の
   タイムスタンプは、Timestamp使用について、SYNとSYN-ACKの間で交渉成
   功を示し、接続の間の何らかの時点での選択確認(SACK)オプションの受信は、
   SACKが交渉されたのを意味します。最初に受信した場合を除き、TCPクッキー
   を使用するホストはSACKブロック送らないことに注意してください。TCP
   接続における一般的な単方向のデータフローで、SACK用法を制限するとき、
   これは問題であるかもしれません。この理由で、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クッキー技術は状
   態をコード化するためにシーケンス番号ビットに加えてタイムスタンプオプ
   ションのビットを使います。Timestamp値がACKパケットのTimestamp Echo
   フィールドで戻ってくるので、基本的SYNクッキーでシーケンス番号や承認
   から回復するのと同じ方法で、タイムスタンプオプションに格納された状態
   も回復できます。タイムスタンプビットを使用すると、典型的なSYNクッキー
   の余地が全く場合でも、ウィンドウ比率やSACK許容やTCP-MD5可能を送受信
   するように明らかに状態ビットを保存できます。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が失われると、送信者は接続が首確立さ
   れたと考えますが、受信側のアプリケーションは、接続の存在について通知
   されて、データは決して送りません。最初のアプリケーションデータが受信
   側から送られるアプリケーション例は、実装がRFC 2822にジョン居する場合
   のSMTPで、ハンドシェイク完了後にservice ready"メッセージが受信側から
   送られます。

   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クッキーが典型的なウェブサーバーで使用された際のエピソー
   ドからすると、あらゆるSYNパケットのためにMD5チェックサムを計算する
   処理の負担は、防備がないときにアプリケーションの可用性の損失と比較し
   て、大きくないように思えます。いくつかの計算能力に制限があるモバイル
   か組み込み機器に関しては、この状況は異なっているかもしれません。

3.7.  Hybrid Approaches
3.7.  組合せ手法

   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クッキーを送ることができます。このような組合せ手法
   はそれぞれの方法の肯定面の強い組み合わせを提供するかもしれません。
   Lemonはこの組合せの効用を説明しました[Lem02]。

3.8.  Firewalls and Proxies
3.8.  ファイアウォールとプロキシ

   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の
   期待するエンドエンドの意味を変更することで関連する他の問題を発生させ
   るかもしれません。これらのファイアウォールとプロキシ製品の中に使用さ
   れた一般的な戦術は、上記の終端ホストのテクニックの1つを実装すること
   で、接続が完全に確立されるまで、保護されたネットワーク上に入ってくる
   SYNを遮断します。これは、ハンドデェークのいくつかの手順で発信側宛と
   受信側宛のいくつかのパケットのソースアドレスを変更することで達成され
   ます[Eddy06]。

4.  Analysis
4.  分析

   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クッキー
   を使用可能にするべきではありません。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月に、Dave Bormanは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はBormanのコードの変更されたバージョンを取り入れま
   した。キャッシュをデフォルトで(すべての接続に)使用するという決定によ
   り元のコードから、2つの注目に値する違いがあります。これはSYN-ACKの
   再送の実施と、より完全なデータを保つのにより大きい構造を使用する必要
   性を意味します。元の構造は、IPv4接続で32バイト長とIPv6をサポートす
   ると56バイトでした、現在のFreeBSDの構造体は196バイト長です。以前に
   引用されるように、LemonはFreeBSD 4.4のSYNキャッシュとクッキーのテク
   ニックを実装しました[Lem02]。Lemonは、完全なTCBの736バイトに比較し
   て、SYNキャッシュ構造が160バイトと書いています(現在のキャッシュ構造
   体は196バイト)。私たちは、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.
   リナックス2.6.5コードは、解析したところ、8つのMSS値をコード化する
   SYNクッキー実装を含み、デフォルトでSYNクッキーを使用ていません。こ
   の機能はリナックスカーネルに2.6.5から数年間存在しています。

   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フローラベル値はそのパケットフローの残りで使用されるフローラベ
   ルと一致しているべきです。SYNキャッシュとSYNクッキーコードの生成する
   SYN-ACKで使用されるフローラベルがランダムになる実装バグがありました
   [MM05]。

   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].
   Windows2000から、マイクロソフトのウインドウズ・オペレーティングシス
   テムには「TCP SYN攻撃保護」の機能がありました、これはレジストリでオ
   ンオフを切り替えできます。Windows2003 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手順
   ハンドシェークで同様に設計されましたが、応答者が状態を予約する前に、
   解かなければいけないパズルを送信者に送ります。サービス妨害攻撃を避
   けるため、状態なしのプロトコル設定の設計に関する一般概念はAuraと
   Nikanderによって議論されました[AN97]。

5.  Security Considerations
5.  セキュリティ問題

   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氾濫攻撃の観測数に影響を及ぼ
   すべきでなく、そのような攻撃に一般的に利用可能な緩和策の使用を奨励
   することで、インターネットの丈夫さを増加させるかもしれません。

6.  Acknowledgements
6.  謝辞

   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.
   Ted Faberとの会話は、この文書を書くきっかけでした。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とLisa Dusseaultからのコメントと提案はこの文書を強化する際に
   役に立ちました。付録Aに記述するTCP SYNクッキーは元々D.J. Bernstein
   の作業です。

   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のAdvanced CommunicationsとNavigationとSurveillance
   Architectures and System Technologies (ACAST)プロジェクトと、Sensis社、
   NASAのSpace Communications Architecture Working GroupとNASAの
   Earth Science   Technology Officeから出ました。


7.  Informative References
7.  有益な参考文献

   [AN97]       Aura, T. and P. Nikander, "Stateless Connections",
                Proceedings of the First International Conference on
                Information and Communication Security, 1997.

   [All07]      Allman, M., "personal communication", February 2007.

   [B96]        Bennahum, D., "PANIX ATTACK", MEME 2.12, October 1996,
                <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.

   [CA-96.21]   CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP
                Spoofing Attacks", September 1996.

   [CB94]       Cheswick, W. and S. Bellovin, "Firewalls and Internet
                Security", ISBN: 0201633574, January 1994.

   [Eddy06]     Eddy, W., "Defenses Against TCP SYN Flooding Attacks",
                Cisco Internet Protocol Journal Volume 8, Number 4,
                December 2006.

   [GN00]       Griffin, M. and J. Nelson, "T/TCP: TCP for
                Transactions", Linux Journal, February 2000.

   [Lem02]      Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN
                Cache", BSDCON 2002, February 2002.

   [MM05]       McGann, O. and D. Malone, "Flow Label Filtering
                Feasibility", European Conference on Computer Network
                Defense 2005, December 2005.

   [MNJH07]     Moskowitz, R., Nikander, P., Jokela, P., and T.
                Henderson, "Host Identity Protocol", Work in Progress,
                June 2007.

   [P48-13]     daemon9, route, and infinity, "Project Neptune", Phrack
                Magazine, Volume 7, Issue 48, File 13 of 18, July 1996.

   [RFC0793]    Postel, J., "Transmission Control Protocol", STD 7,
                RFC 793, September 1981.

   [RFC1144]    Jacobson, V., "Compressing TCP/IP headers for low-speed
                serial links", RFC 1144, February 1990.

   [RFC1321]    Rivest, R., "The MD5 Message-Digest Algorithm",
                RFC 1321, April 1992.

   [RFC1644]    Braden, B., "T/TCP -- TCP Extensions for Transactions
                Functional Specification", RFC 1644, July 1994.

   [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.

   [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.

   [RFC3013]    Killalea, T., "Recommended Internet Service Provider
                Security Services and Procedures", BCP 46, RFC 3013,
                November 2000.

   [RFC3704]    Baker, F. and P. Savola, "Ingress Filtering for
                Multihomed Networks", BCP 84, RFC 3704, March 2004.

   [RFC4413]    West, M. and S. McCann, "TCP/IP Field Behavior",
                RFC 4413, March 2006.

   [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.

   [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.

   [Ste95]      Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume
                2: The Implementation", January 1995.

   [cr.yp.to]   Bernstein, D., "SYN cookies", visited in December 2005,
                <http://cr.yp.to/syncookies.html>.

   [win2k3-wp]  Microsoft Corporation, "Microsoft Windows Server 2003
                TCP/IP Implementation Details", White Paper, July 2005.


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.
   この情報はBernsteinのSYNクッキーのウェブページから得られました
   [cr.yp.to]。これはそのウェブページの技術資料の書き直しで、完全な置
   き換えではありません。SYNクッキー概念を実装には、ここで説明された手
   段とわずかに異なる実装方法があります、がSYN-ACKシーケンス番号にデー
   タを符号化する基本的な考え方は一定です。

   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クッキーはSYN-ACKで送られた初期シーケンス番号です、これは接続開
   始者の初期シーケンス番号とMSSと時間カウンタと関連アドレスとポート番
   号に基づいて選ばれています。SYNクッキーを含む実際のビットは、SYNの
   シーケンス番号と32ビットデータのビット単位の差分(排他的論理輪)
   で選択されます32ビットデータは上位5ビットは64秒毎に増加する
   32ビットのカウンタ値を32で割った余りで、次の3ビットはSYNのMSS
   に近い使用可能な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.
   Bernsteinのウェブページ[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クッキーアルゴリズムの最も良い記述は、Bernsteinからのメール
   の一部にあり、メールはウェブサイトに格納されています(これが前に書い
   たカウンタを32で割った5ビットを先頭に設定しないのに注意してください、
   その代わりに2番目のMD5操作からの29ビットとMSS表のインデックスの3ビッ
   トを使用します;また、秘密値の設定は議論しません)。この章の残りは
   Bernsteinのメール[cr.yp.to]から抜粋されます:

      Here's what an implementation would involve:
      ここに、実装に必要なものがあります:

         Maintain two (constant) secret keys, sec1 and sec2.
         2個の(定数)の秘密鍵、sec1およびsec2を維持してください。

         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
         ISNがxで(saddr,sport)から(daddr,dport)へのSYNが到着すると、
         入力MSS以下のmsstab[i]に対する最大のiを探します。以下を計算
         します。

            z = MD5(sec1,saddr,sport,daddr,dport,sec1)

               + x

               + (counter << 24)

               + (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 <<
               24))

         and then
         そして

            y = (i << 29) + (z % (1 << 29))

         Create a TCB as usual, with y as our ISN.  Send back a SYNACK.
         とします。yをISNとして通常通りで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.
         例外:もし_私たちがTCBsのためのメモリを使い果たしたなら、「最後
         のオーバーフロー時間」から現在の時間を設定してください。すべて
         のしゃれたオプションがオフにされている状態で、とにかくSYNACKを
         送ってください。

         When an ACK comes back, follow this procedure to find a TCB:
         ACKが戻ったらこの手順に従って、TCBを見つけてください:

         (1)  Look for a (saddr,sport,daddr,dport) TCB.  If it's there,
              done.
         (1)  TBC(saddr,sport,daddr,dport)をみます。もしそれがそこに
              あるなら終わりです。

         (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を再計算し、いずれかのyが下位
              29ビットの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

   Phone: 216-433-6682
   EMail: 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.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして
   この中に明らかにされる以外は著者がすべての権利を維持します。

   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.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とIETF信託とインターネット技術標準化タスクフォースは、明確にも暗
   黙にも、この情報の使用が権利の侵害しないことや商業利用や特別の目的へ
   の利用に適当である事の保障を含め、全ての保証を拒否します。

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文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So