[要約] 要約：RFC 4953は、TCPのスプーフィング攻撃に対する防御策を提案しています。 目的：このRFCの目的は、TCPのセキュリティを向上させ、スプーフィング攻撃から保護することです。
Network Working Group J. Touch
Request for Comments: 4953 USC/ISI
Category: Informational July 2007
Defending TCP Against Spoofing Attacks
スプーフィング攻撃からTCPを守る
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）The IETF Trust（2007）。
Abstract
概要
Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.
コアインターネットインフラストラクチャに対する潜在的な攻撃の最近の分析は、偽造IPソースアドレス（スプーフィング）で送信されるスプリアスリセット（RSTS）へのTCP接続の脆弱性の増加を示しています。TCPは常にこのようなRSPoofing攻撃の影響を受けやすく、RSTシーケンス番号が現在の受信ウィンドウ内にあることを確認することで間接的に保護され、TCPエンドポイントとポート番号の難読化を通じて。BGPなどの予測可能なポートペアやWebサーバーやよく知られている大規模なキャッシュの間で、よく知られているエンドポイントのペアの場合、接続のパス帯域幅遅延積の増加により、受信ウィンドウスペースが十分に増加しました。PATHサードパーティは、ブルートフォースが実行可能なRSTシーケンス番号を生成できます。攻撃の感受性は帯域幅の正方形とともに増加し、したがって最近の高速ネットワークに大きな脆弱性を示します。このドキュメントは、この脆弱性に対処し、輸送レベルで提案されたソリューションとその固有の課題、既存のネットワークレベルのソリューションとその展開の実現可能性について説明します。このドキュメントは、スプーフィングされたTCPセグメントによる脆弱性に焦点を当てており、TCP接続に対する関連するICMPスプーフィング攻撃の議論が含まれています。
Table of Contents
目次
1. Introduction ....................................................3
2. Background ......................................................4
2.1. Review of TCP Windows ......................................5
2.2. Recent BGP Attacks Using TCP RSTs ..........................6
2.3. TCP RST Vulnerability ......................................6
2.4. What Changed - the Ever-Opening Advertised Receive Window ..7
3. Proposed Solutions and Mitigations .............................10
3.1. Transport Layer Solutions .................................10
3.1.1. TCP MD5 Authentication .............................11
3.1.2. TCP RST Window Attenuation .........................11
3.1.3. TCP Timestamp Authentication .......................12
3.1.4. Other TCP Cookies ..................................13
3.1.5. Other TCP Considerations ...........................13
3.1.6. Other Transport Protocol Solutions .................14
3.2. Network Layer (IP) Solutions ..............................14
3.2.1. Address Filtering ..................................15
3.2.2. IPsec ..............................................16
4. ICMP ...........................................................17
5. Issues .........................................................18
5.1. Transport Layer (e.g., TCP) ...............................18
5.2. Network Layer (IP) ........................................19
5.3. Application Layer .........................................21
5.4. Link Layer ................................................21
5.5. Issues Discussion .........................................21
6. Security Considerations ........................................22
7. Conclusions ....................................................23
8. Acknowledgments ................................................23
9. Informative References .........................................24
Analysis of the Internet infrastructure has recently demonstrated a new version of a vulnerability in BGP connections between core routers using an attack based on RST spoofing from off-path attackers [9][10][48]. The attack itself is not new, having been documented nearly six years earlier [20]. Such connections, typically using TCP, can be susceptible to off-path third-party reset (RST) segments with forged source addresses (spoofed), which terminate the TCP connection. BGP routers react to a terminated TCP connection in various ways, which can amplify the impact of an attack, ranging from restarting the connection to deciding that the other router is unreachable and thus flushing the BGP routes [37]. This sort of attack affects other protocols besides BGP, involving any long-lived connection between well-known endpoints. The impact on the Internet infrastructure can be substantial (especially for the BGP case), and warrants immediate attention.
インターネットインフラストラクチャの分析により、最近、オフパス攻撃者[9] [10] [48]からの最初のスプーフィングに基づく攻撃を使用して、コアルーター間のBGP接続の脆弱性の新しいバージョンが実証されました。攻撃自体は新しいものではなく、ほぼ6年前に記録されています[20]。通常、TCPを使用するこのような接続は、TCP接続を終了するForged Sourceアドレス（スプーフィング）を備えたオフパスサードパーティリセット（RST）セグメントの影響を受けやすくなります。BGPルーターは、さまざまな方法で終了したTCP接続に反応します。これは、接続の再起動から他のルーターが到達できないことを決定し、したがってBGPルートをフラッシングすることまで、攻撃の影響を増幅できます[37]。この種の攻撃は、BGP以外のプロトコルに影響を与え、よく知られているエンドポイント間の長期的な接続が含まれます。インターネットインフラストラクチャへの影響は相当なものであり（特にBGPの場合）、即座に注意を払う必要があります。
TCP, like many other protocols, can be susceptible to these off-path third-party spoofing attacks. Such attacks rely on the increase of commodity platforms supporting public access to previously privileged resources, such as system-level (i.e., root) access. Given such access, it is trivial for anyone to generate a packet with any header desired.
TCPは、他の多くのプロトコルと同様に、これらのオフパスサードパーティのスプーフィング攻撃の影響を受けやすい場合があります。このような攻撃は、システムレベル（つまり、ルート）アクセスなど、以前に特権的なリソースへのパブリックアクセスをサポートする商品プラットフォームの増加に依存しています。そのようなアクセスを考えると、誰もが必要なヘッダーを使用してパケットを生成することは些細なことです。
This, coupled with the lack of sufficient address filtering to drop such spoofed traffic, can increase the potential for off-path third-party spoofing attacks [9][10][48]. Proposed solutions include the deployment of existing Internet network and transport security as well as modifications to transport protocols that reduce its vulnerability to generated attacks [13][15][20][36][46].
これは、そのようなスプーフィングされたトラフィックを落とすのに十分なアドレスフィルタリングの欠如と相まって、パス外のサードパーティのスプーフィング攻撃の可能性を高める可能性があります[9] [10] [48]。提案されたソリューションには、既存のインターネットネットワークと輸送セキュリティの展開、および生成された攻撃に対する脆弱性を低下させる輸送プロトコルへの変更が含まれます[13] [15] [20] [36] [46]。
One way to defeat spoofing is to validate the segments of a connection, either at the transport level or the network level. TCP with MD5 extensions provides this authentication at the transport level, and IPsec provides authentication at the network level [20][24][27]. In both cases, their deployment overhead may be prohibitive, e.g., it may not be feasible for public services, such as web servers, to be configured with the appropriate certificate authorities of large numbers of peers (for IPsec using the Internet Key Exchange Protocol (IKE)), or shared secrets (for IPsec in shared-secret mode, or TCP/MD5), because many clients may need to be configured rapidly without external assistance. Services located on public web servers connecting to large-scale caches or BGP with larger numbers of peers can fall into this category.
スプーフィングを打ち負かす1つの方法は、輸送レベルまたはネットワークレベルのいずれかで、接続のセグメントを検証することです。MD5拡張機能を備えたTCPは、輸送レベルでこの認証を提供し、IPSECはネットワークレベルで認証を提供します[20] [24] [27]。どちらの場合も、展開間の展開は法外なものである可能性があります。たとえば、Webサーバーなどの公共サービスが多数のピアの適切な証明書当局で構成される可能性があります（Internet Key Exchange Protocolを使用するIPSECの場合（ike））、または共有秘密（共有分泌モードのIPSECの場合、またはTCP/MD5の場合）。大規模なキャッシュまたはBGPに大量のピアを接続するパブリックWebサーバーにあるサービスは、このカテゴリに分類される可能性があります。
The remainder of this document outlines the recent attack scenario in detail and describes and compares a variety of solutions, including existing solutions based on TCP/MD5 and IPsec, as well as recently proposed solutions, including modifications to TCP's RST processing [36], modifications to TCP's timestamp processing [34], and modifications to IPsec and TCP/MD5 keying [45]. This document focuses on spoofing of TCP segments, although a discussion of related spoofing of ICMP packets based on spoofed TCP contents is also discussed.
このドキュメントの残りの部分は、最近の攻撃シナリオの詳細を概説し、TCP/MD5およびIPSECに基づく既存のソリューションを含むさまざまなソリューション、およびTCPのRST処理[36]、修正の修正を含む最近提案されたソリューションを含むさまざまなソリューションを説明および比較します。TCPのタイムスタンプ処理[34]、およびIPSECおよびTCP/MD5キーイングの変更[45]。このドキュメントは、TCPセグメントのスプーフィングに焦点を当てていますが、スプーフィングされたTCP含有量に基づいたICMPパケットの関連するスプーフィングの議論についても説明します。
Note that the description of these attacks is not new; attacks using RSTs on BGP have been known since 1998, and were the reason for the development of TCP/MD5 [20]. The recent attack scenario was first documented by Convery at a NANOG (North American Network Operators' Group) meeting in 2003, but that analysis assumed the entire sequence space (2^32 packets) needed to be covered for an attack to succeed [10]. Watson's more detailed analysis discovered that a single packet anywhere in the current window could succeed at an attack [48]. This document adds the observation that susceptibility to attack is directly proportional to the square of bandwidth, due to the coupling between the linear increase in receive window size and linear increase in rate of a potential attack, as well as comparing the variety of more recent proposals, including modifications to TCP, use of IPsec, and use of TCP/MD5 to resist such attacks.
これらの攻撃の説明は新しいものではないことに注意してください。BGPでのRSTを使用した攻撃は1998年以来知られており、TCP/MD5の開発の理由でした[20]。最近の攻撃シナリオは、2003年のNanog（北米ネットワークオペレーターグループ）会議でのConveryによって最初に文書化されましたが、その分析では、攻撃を成功させるためにシーケンススペース全体（2^32パケット）をカバーする必要があると仮定しました[10]。ワトソンのより詳細な分析により、現在のウィンドウのどこでも単一のパケットが攻撃で成功する可能性があることが発見されました[48]。このドキュメントは、攻撃に対する感受性は、受信ウィンドウサイズの線形増加と潜在的な攻撃の速度の線形増加との間の結合と、より最近の提案の多様性を比較するため、帯域幅の正方形に直接比例するという観察を追加します。、TCPへの変更、IPSECの使用、およびTCP/MD5の使用を含むためのTCP/MD5の使用。
The recent analysis of potential attacks on BGP has again raised the issue of TCP's vulnerability to off-path third-party spoofing attacks [9][10][48]. A variety of such attacks have been known for several years, including sending RSTs, SYNs, and even ACKs in an attempt to affect an existing connection or to load down servers. These attacks often combine external knowledge (e.g., to indicate the IP addresses to attack, the destination port number, and sometimes the Initial Sequence Number (ISN)) with brute-force capabilities enabled by modern computers and network bandwidths (e.g., to scan all source ports or an entire window space). Overall, such attacks are countered by the use of some form of authentication at the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or other layers. TCP already includes a weak form of such authentication in its check of segment sequence numbers against the current receiver window. Increases in the bandwidth-delay product for certain long connections have sufficiently weakened this type of weak authentication to make reliance on it inadvisable.
BGPに対する潜在的な攻撃の最近の分析により、TCPのサードパーティのスプーフィング攻撃に対するTCPの脆弱性の問題が再び提起されました[9] [10] [48]。このような攻撃は、既存の接続に影響を与えたり、サーバーをロードしたりするために、RST、Syn、さらにはACKを送信するなど、数年間知られています。これらの攻撃は、多くの場合、外部の知識を組み合わせて（例えば、攻撃へのIPアドレス、宛先ポート番号、時には初期シーケンス番号（ISN）を示すために、最新のコンピューターとネットワーク帯域幅によって有効なブルートフォース機能（たとえば、すべてをスキャンするために）ソースポートまたはウィンドウスペース全体）。全体として、このような攻撃は、ネットワーク（IPSECなど）、輸送（Syn Cookie、TCP/MD5など）、またはその他の層での何らかの認証を使用することにより反論されます。TCPには、現在のレシーバーウィンドウに対するセグメントシーケンス番号のチェックには、このような認証の弱い形式が既に含まれています。特定の長い接続の帯域幅遅延製品の増加は、このタイプの弱い認証を十分に弱め、それを依存できないようにしました。
Before proceeding, it is useful to review the terminology and components of TCP's windowing algorithm. TCP connections have three kinds of windows [1][35]:
先に進む前に、TCPのウィンドウアルゴリズムの用語とコンポーネントを確認することが役立ちます。TCP接続には3種類のウィンドウがあります[1] [35]：
o Send window (SND.WND): the latest send window size.
o Window（and.End）を送信：最新の送信ウィンドウサイズ。
o Receive window (RCV.WND): the latest advertised receive window size.
o 受信ウィンドウ（rcv.and）：最新の宣伝された受信ウィンドウサイズ。
o Congestion window (CWND): the window determined by congestion feedback that limits how much of RCV.WND can be in-flight in a round-trip time.
o 輻輳ウィンドウ（CWND）：rcv.wndのどれだけが往復時間で飛行できることを制限する混雑フィードバックによって決定されるウィンドウ。
For TCP connections in most modern implementations, SND.WND and RCV.WND are the size of the corresponding send and receive socket buffers, and are configurable using socket buffer resizing commands.
ほとんどの最新の実装でのTCP接続の場合、SND.WNDおよびRCV.WNDは、対応する送信および受信ソケットバッファのサイズであり、ソケットバッファのサイズ変更コマンドを使用して構成可能です。
CWND determines how much data can be in transit in a round-trip time, SND.WND determines how much data the sender is willing to store on its side for possible retransmission due to loss, and RCV.WND determines the ability of the receiver to accommodate that loss and reorder received packets. CWND never grows beyond RCV.WND.
CWNDは、往復時間に輸送中のデータの量を決定し、SND.WNDは、送信者が損失のために再送信の可能性のためにその側に保存するデータの量を決定し、RCV.WNDは受信者の能力を決定しますその損失に対応し、受信したパケットを再注文します。cwndはrcv.wndを超えて成長することはありません。
High bandwidth-delay product networks need CWND to be sufficiently large to accommodate as much data as can be in transit in a round trip time; otherwise, their performance will suffer. As a result, it is recommended that users and various automatic programs increase RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay product) [23][38].
高帯域幅遅延製品ネットワークは、往復時間に輸送中にできる限り多くのデータに対応するために十分に大きくする必要があります。そうでなければ、彼らのパフォーマンスは苦しむでしょう。その結果、ユーザーとさまざまな自動プログラムがRCV.WNDを少なくとも帯域幅*遅延（帯域幅遅延製品）のサイズに増やすことをお勧めします[23] [38]。
As the bandwidth-delay product of the network increases, however, such increases in the advertised receive window can cause increased susceptibility to spoofing attacks, as the remainder of this document shows. This assumes, however, that the receive window size (e.g., via increased receive socket buffer configuration) is increased with the increased bandwidth-delay product; if not, then connection performance will degrade, but susceptibility to spoofing attacks will increase only linearly (with the rate at which the attacker can send spoofed packets), not as the square of the bandwidth. Note that either increase depends on the receive window itself, and is independent of the congestion state or amount of data transmitted.
ただし、ネットワークの帯域幅遅延積が増加するにつれて、このドキュメントの残りが示すように、広告の受信ウィンドウのこのような増加は、攻撃のスプーフィング攻撃に対する感受性の増加を引き起こす可能性があります。ただし、これは、帯域幅遅延製品の増加とともに、受信ウィンドウサイズ（たとえば、受信ソケットバッファー構成の増加を介して）が増加することを前提としています。そうでない場合、接続性能は低下しますが、スプーフィング攻撃に対する感受性は、帯域幅の正方形としてではなく、攻撃者がスプーフィングされたパケットを送信できる速度では（攻撃者がスプーフィングされたパケットを送信できる速度で）直線的に増加します。いずれかの増加は、受信ウィンドウ自体に依存し、輻輳状態または送信されるデータの量に依存しないことに注意してください。
BGP represents a particular vulnerability to spoofing attacks because it uses TCP connectivity to infer routability, so losing a TCP connection with a BGP peer can result in the flushing of routes to that peer [37].
BGPは、TCP接続を使用してルーティング可能性を推測するため、スプーフィング攻撃に対する特定の脆弱性を表しているため、BGPピアとのTCP接続を失うと、そのピアへのルートが洗い流される可能性があります[37]。
Until six years ago, such connections were assumed difficult to attack because they were described by a few comparatively obscure parameters [20]. Most TCP connections are protected by multiple levels of obfuscation except at the endpoints of the connection:
6年前まで、そのような接続は、いくつかの比較的曖昧なパラメーターによって説明されたため、攻撃が困難であると想定されていました[20]。ほとんどのTCP接続は、接続のエンドポイントを除き、複数のレベルの難読化によって保護されています。
o Both endpoint addresses are usually not well-known; although server addresses are advertised, clients are somewhat anonymous.
o 両方のエンドポイントアドレスは通常よく知られていません。サーバーアドレスは宣伝されていますが、クライアントはやや匿名です。
o Both port numbers are usually not well-known; the server's is usually advertised (representing the service), but the client's is typically sufficiently unpredictable to an off-path third-party.
o 通常、両方のポート番号はよく知られていません。サーバーは通常宣伝されています（サービスを表します）が、クライアントは通常、オフパスのサードパーティにとって十分に予測不可能です。
o Valid sequence number space is not well-known.
o 有効なシーケンス番号スペースはよく知られていません。
o Connections are relatively short-lived and valid sequence space changes, so any attempt to guess (e.g., by external knowledge or brute force) the above information is unlikely to be useful.
o 接続は比較的短命で有効なシーケンススペースが変更されるため、上記の情報が有用である可能性は低いと推測しようとする試み（たとえば、外部の知識やブルートフォースによる）。
BGP represents an exception to the above criteria (though not the only case). Both endpoints can be well-known, or guessed using hints from part of an AS path. The destination port is typically fixed to indicate the BGP service. The source port used by a BGP router is sometimes fixed and advertised to enable firewall configuration; even when not fixed, there are only approximately 65,000 valid source ports, which thus may be exhaustively attacked. Connections are long- lived, and, as noted before, some BGP implementations interpret successive TCP connection failures as routing failures, discarding the corresponding routing information. In addition, the valid sequence number space once thought to provide some protection has been significantly weakened by increasing advertised receive window sizes.
BGPは、上記の基準の例外を表します（ただし、唯一のケースではありません）。どちらのエンドポイントもよく知られているか、ASパスの一部からのヒントを使用して推測することができます。宛先ポートは通常、BGPサービスを示すために固定されています。BGPルーターが使用するソースポートは、ファイアウォールの構成を有効にするために固定され、宣伝されることがあります。修正されていない場合でも、約65,000の有効なソースポートしかありません。したがって、徹底的に攻撃される可能性があります。接続は長生きされており、前に述べたように、一部のBGP実装は、連続したTCP接続障害をルーティング障害と解釈し、対応するルーティング情報を破棄します。さらに、かつて何らかの保護を提供すると考えられていた有効なシーケンス番号スペースは、宣伝された受信ウィンドウサイズを増やすことで大幅に弱体化されています。
TCP has a known vulnerability to third-party spoofed segments. SYN flooding consumes server resources in half-open connections, affecting the server's ability to open new connections [4][11]. ACK spoofing can cause connections to transmit too much data too quickly, creating network congestion and segment loss, causing connections to slow to a crawl. In the most recent attacks on BGP, RSTs cause connections to be dropped. As noted earlier, some BGP implementations interpret TCP connection termination, or a series of such failures, as a network failure [37]. This causes routers to drop the BGP routing information already exchanged, in addition to inhibiting their ongoing exchanges, thus amplifying the impact of the attack. The result can affect routing paths throughout the Internet.
TCPは、サードパーティのスプーフィングされたセグメントに対して既知の脆弱性を持っています。Syn Floodingは、ハーフオープン接続でサーバーリソースを消費し、新しい接続を開くサーバーの能力に影響します[4] [11]。ACKスプーフィングにより、接続があまりにも速くデータを送信しすぎて、ネットワークの混雑とセグメントの損失が発生し、接続がクロールに遅くなります。BGPに対する最新の攻撃では、RSTSにより接続が削除されます。前述のように、一部のBGP実装は、ネットワークの障害としてTCP接続終了、または一連のそのような障害を解釈します[37]。これにより、ルーターは継続的な交換を阻害することに加えて、既に交換されているBGPルーティング情報をドロップし、攻撃の影響を増幅します。結果は、インターネット全体のルーティングパスに影響を与える可能性があります。
The dangerous effects of RSTs on TCP have been known for many years, even when used by the legitimate endpoints of a connection. TCP RSTs cause the receiver to drop all connection state; because the source is not required to maintain a TIME_WAIT state, such a RST can cause premature reuse of address/port pairs, potentially allowing segments from a previous connection to contaminate the data of a new connection, known as TIME_WAIT assassination [8]. In this case, assassination occurs inadvertently as the result of duplicate segments from a legitimate source, and can be avoided by blocking RST processing while in TIME_WAIT. However, assassination can be useful to deliberately reduce the state held at servers; this requires that the source of the RSTs go into TIME_WAIT state to avoid such hazards, and that RSTs are not blocked in the TIME_WAIT state [12].
TCPに対するRSTの危険な効果は、接続の正当なエンドポイントで使用された場合でも、長年知られています。TCP RSTSにより、受信機はすべての接続状態をドロップします。ソースはtime_wait状態を維持する必要がないため、このようなRはアドレス/ポートペアの早期の再利用を引き起こす可能性があり、潜在的に以前の接続からセグメントを許可して、time_wait暗殺として知られる新しい接続のデータを汚染します[8]。この場合、暗殺は正当なソースからの重複セグメントの結果として不注意に発生し、Time_waitで最初の処理をブロックすることで回避できます。ただし、暗殺は、サーバーで保持されている状態を意図的に減らすのに役立ちます。これには、RSTのソースがそのような危険を回避するためにTime_Wait状態に入り、RSTがTime_Wait状態でブロックされないことが必要です[12]。
Firewalls and load balancers, so-called 'middleboxes', sometimes emit RSTs on behalf of transited connections to optimize server performance, as noted in RFC 3360 [14]. This is effectively an on-path RST attack in which the RSTs are sent for benign or beneficial intent. There are numerous hazards with such use of RSTs, outlined in that RFC.
RFC 3360 [14]に記載されているように、ファイアウォールとロードバランサー、いわゆる「ミドルボックス」は、サーバーのパフォーマンスを最適化するためにTransited Connectionsに代わってRSTを放出することがあります。これは、事実上、RSTが良性または有益な意図のために送られるパス上の攻撃です。RFCで概説されているRSTSのこのような使用には多くの危険があります。
RSTs represent a hazard to TCP, especially when completely unvalidated. Fortunately, there are a number of obfuscation mechanisms that make it difficult for off-path third parties to forge (spoof) valid RSTs, as noted earlier. We have already shown it is easy to learn both endpoint addresses and ports for some protocols, notably BGP. The final obfuscation is the segment sequence number.
RSTは、特に完全に検証されていない場合、TCPに対する危険を表します。幸いなことに、前述のように、パス外のサードパーティが有効なRSTを偽造（スプーフ）することを困難にする難読化メカニズムがいくつかあります。いくつかのプロトコル、特にBGPのエンドポイントアドレスとポートの両方を簡単に学習できることをすでに示しています。最後の難読化は、セグメントシーケンス番号です。
TCP segments include a sequence number, which enables out-of-order receiver processing as well as duplicate detection. The sequence number space is also used to manage congestion, and indicates the index of the next byte to be transmitted or received. For RSTs, this is relevant because legitimate RSTs use the next sequence number in the transmitter window, and the receiver checks that incoming RSTs have a sequence number in the expected receive window. Such processing is intended to eliminate duplicate segments (somewhat moot for RSTs, though), and to drop RSTs that were part of previous connections.
TCPセグメントには、オーダーオブオーダーレシーバー処理と重複検出を可能にするシーケンス番号が含まれています。シーケンス番号スペースは、うっ血を管理するためにも使用され、送信または受信される次のバイトのインデックスを示します。RSTの場合、これは正当なRSTSが送信機ウィンドウで次のシーケンス番号を使用し、受信者が受信RSTSが予想される受信ウィンドウにシーケンス番号があることをチェックするため、これは関連性があります。このような処理は、重複したセグメントを排除することを目的としています（ただし、RSTSにはやや誤解してください）、以前の接続の一部であるRSTをドロップすることを目的としています。
TCP uses two window mechanisms, a primary mechanism for reordering and congestion control (which uses a space of 32 bits), and a secondary mechanism that scales this window [23][35]. The valid advertised receive window is a fraction, not to exceed approximately half, of this space, or ~2 billion (2 * 10^9, i.e., 2E9 or 2 U.S. billion). Under typical configurations, the majority of TCP connections open to a very small fraction of this space, e.g., 10,000-60,000(approximately 5-100 segments). This is because the advertised receive window typically matches the receive socket buffer size. It is recommended that this buffer be tuned to match the needs of the connection, either manually or by automatic external means [38].
TCPは、2つのウィンドウメカニズムを使用しています。これは、並べ替えと輻輳制御の主要なメカニズム（32ビットのスペースを使用）と、このウィンドウを拡大する二次メカニズムです[23] [35]。有効な広告の受信ウィンドウは、このスペースの約半分を超えるものではなく、20億（2 * 10^9、つまり2E9または2億）です。典型的な構成の下では、TCP接続の大部分は、このスペースのごく一部、たとえば10,000〜60,000（約5〜100セグメント）に開かれています。これは、広告された受信ウィンドウが通常、受信ソケットバッファのサイズと一致するためです。このバッファーは、手動または自動外部平均のいずれかによって、接続のニーズに合うように調整することをお勧めします[38]。
On a low-loss path, the advertised receive window should be configured to match the path bandwidth-delay product, including buffering delays (assume 1 packet/hop) [38]. Many paths in the Internet have end-to-end bandwidths of under 1 Mbps, latencies under 100 ms, and are under 15 hops, resulting in fairly small advertised receive windows as above (under 35,000 bytes). Under these conditions, and further assuming that the initial sequence number is suitably (pseudo-randomly) chosen, a valid guessed sequence number would have odds of 1 in 57,000 of falling within the advertised receive window. Put differently, a blind (i.e., off-path) attacker would need to send 57,000 RSTs with suitably spaced sequence number guesses within one round-trip time to successfully reset a connection. At 1 Mbps, 57,000 (40 byte) RSTs would take only 20 seconds to transmit, but this presumes that both IP addresses and both ports are known. Absent knowledge of the source port, an off-path spoofer would need to try at least the entire range of 49152- 65535, or 16,384 different ports, resulting in an attack that would take over 91 hours. Because most TCP connections are comparatively short-lived, even this moderate variation in the source port is sufficient for such environments, although further port randomization may be recommended [29].
低損失パスでは、広告の受信ウィンドウは、バッファリング遅延（1パケット/ホップを仮定）を含むパス帯域幅遅延製品に一致するように構成する必要があります[38]。インターネット内の多くのパスは、1 Mbps未満のエンドツーエンドの帯域幅、100ミリ秒未満のレイテンシを持ち、15ホップ未満であるため、上記のようにかなり小さな広告を受け取るウィンドウ（35,000バイト未満）になります。これらの条件下で、さらに、初期シーケンス数が適切であると仮定すると（擬似ランダムリー）選択された場合、有効な推測されたシーケンス番号は、宣伝された受信ウィンドウに落ちる57,000人に1のオッズを持っています。別の言い方をすれば、盲目の（すなわち、オフパス）攻撃者は、接続を正常にリセットするために、1回の往復時間内に適切に間隔を空けたシーケンス番号推測を備えた57,000 RSTSを送信する必要があります。1 Mbpsでは、57,000（40バイト）RSTSが送信に20秒しかかかりませんが、これは両方のIPアドレスと両方のポートが既知であると推定しています。ソースポートの知識がなければ、オフパススプーファーは、少なくとも49152-65535または16,384の異なるポートの全範囲を試す必要があり、その結果、91時間を超える攻撃が発生します。ほとんどのTCP接続は比較的短命であるため、ソースポートのこの中程度の変動でさえ、そのような環境には十分ですが、さらなるポートのランダム化が推奨される場合があります[29]。
Recent use of high bandwidth paths of 10 Gbps and higher results in bandwidth-delay products over 125 MB -- approximately 1/10 of TCP's overall maximum advertised receive window size (i.e., assuming the receive socket buffers are increased as much as possible) excluding scale, assuming the receiver allocates sufficient buffering (as discussed in Section 2). Even under networks that are ten times slower (1 Gbps), the active advertised receive window covers 1/100th of the overall window size. At these speeds, it takes only 10-100 packets, or less than 32 microseconds, to correctly guess a valid sequence number and kill a connection. A table of corresponding exposure to various amounts of RSTs is shown below, for various line rates, assuming the more conventional 100-ms latencies (though even 100 ms is large for BGP cases):
125 MBを超える帯域幅遅延製品の10 gbpsの高い帯域幅経路とより高い結果の最近の使用 - TCPの全体的な最大広告の受信ウィンドウサイズの約1/10（つまり、受信ソケットバッファが可能な限り増加すると仮定して）レシーバーが十分なバッファリングを割り当てると仮定すると、スケール（セクション2で説明しているように）。10倍遅いネットワーク（1 gbps）であっても、アクティブな宣伝されているウィンドウの受信ウィンドウは、全体のウィンドウサイズの1/100をカバーしています。これらの速度では、有効なシーケンス番号を正しく推測して接続を殺すには、10〜100個のパケット、または32マイクロ秒未満のパケットのみが必要です。さまざまな量のRSTSへの対応する曝露の表を、より従来の100ミリ秒のレイテンシーを想定して、さまざまなラインレートについて以下に示します（ただし、BGPケースでは100ミリ秒でさえ大きいです）：
BW BW*delay RSTs needed Time needed
------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours
Figure 1: Time needed to kill a connection
図1：接続を殺すのに必要な時間
This table demonstrates that the effect of bandwidth on the vulnerability is squared; for every increase in bandwidth, there is a linear decrease in the number of sequence number guesses needed, as well as a linear decrease in the time needed to send a set of guesses. Notably, as inter-router link bandwidths approach 1 Mbps, an 'exhaustive' attack becomes practical. Checking that the RST sequence number is somewhere in the advertised receive window, out of the overall maximum receive window (2^32), is an insufficient obfuscation.
この表は、脆弱性に対する帯域幅の効果が二乗されていることを示しています。帯域幅が増加するたびに、必要なシーケンス数の推測の数が線形減少し、一連の推測を送信するのに必要な時間の線形減少があります。特に、ルーター間リンクの帯域幅が1 Mbpsに近づくと、「徹底的な」攻撃が実用的になります。RSTシーケンス番号が広告された受信ウィンドウのどこかにあることを確認すると、最大受信ウィンドウ（2^32）のうち、難読化が不十分です。
Note that this table makes a number of assumptions:
このテーブルは多くの仮定を行っていることに注意してください。
1. The overall bandwidth-delay product is relatively fixed.
1.
2. Traffic losses are negligible (insufficient to affect the congestion window over the duration of most of the connection).
2. トラフィックの損失はごくわずかです（接続のほとんどの期間にわたって混雑ウィンドウに影響を与えるには不十分です）。
3. The advertised receive window is a large fraction of the overall maximum receive window size, e.g., because the receive socket buffers are set to match a large bandwidth-delay product.
3. 広告された受信ウィンドウは、受信ソケットバッファーが大きな帯域幅遅延製品に一致するように設定されているため、全体の最大受信ウィンドウサイズの大部分です。
4. The attack bandwidth is similar to the end-to-end path bandwidth.
4. 攻撃帯域幅は、エンドツーエンドのパス帯域幅に似ています。
Of these assumptions, the last two are more notable. The issue of receive socket buffers was discussed in Section 2. Figure 1 summarized the time to a successful attack based on large advertised receive windows, but many current commercial routers have limits of 128 KB for large devices, 32 KB for medium, and as little as 4 KB for modest ones. Figure 2 shows the time and bandwidths needed to accomplish an attack on BGP sessions in the time shown for 100-ms latencies; for even short-range network latencies (10 ms), these sessions can be still be attacked over short timescales (minutes to hours).
これらの仮定のうち、最後の2つはより注目に値します。受信ソケットバッファーの問題についてはセクション2で説明しました。図1は、広告の受信ウィンドウに基づいて攻撃を成功させるための時間をまとめましたが、多くの現在の市販のルーターには、大規模なデバイスでは128 kb、媒体では32 kb、および少量の制限があります。控えめなものの4 kbとして。図2は、100 msのレイテンシについて示されている時間のBGPセッションに対する攻撃を達成するために必要な時間と帯域幅を示しています。短距離ネットワークレイテンシ（10ミリ秒）でさえ、これらのセッションは、短いタイムスケール（数分から数時間）でまだ攻撃される可能性があります。
Receive
BW Buffer Size RSTs needed Time needed
------------------------------------------------------------
10 Mbps 0.128 MB 33,555 1 second
3 Mbps 0.032 MB 134,218 40 seconds
300 Kbps 0.004 MB 1,073,742 1 hour
Figure 2: Time needed to kill a connection with limited buffers
図2：限られたバッファーで接続を殺すのに必要な時間
The issue of the attack bandwidth is considered reasonable as follows:
攻撃帯域幅の問題は、次のように妥当と見なされます。
1. RSTs are substantially easier to send than data; they can be precomputed and they are smaller than data packets (40 bytes).
1. RSTは、データよりも送信が大幅に簡単です。それらは事前に計算される可能性があり、データパケット（40バイト）よりも小さいです。
2. Although susceptible connections use somewhat less ubiquitous high-bandwidth paths, the attack may be distributed, at which point only the ingress link of the attack is the primary limitation.
2. 感受性のつながりは、遍在する高帯域幅のパスをやや少なく使用しますが、攻撃は分散される場合があります。その時点で、攻撃の侵入リンクのみが主要な制限です。
3. For the purposes of the above table, we assume that the ingress at the attack has the same bandwidth as the path, as an approximation.
3. 上記の表の目的のために、攻撃の侵入は近似としてパスと同じ帯域幅を持っていると仮定します。
The previous sections discussed the nature of the recent attacks on BGP due to the vulnerability of TCP to RST spoofing attacks, due largely to recent increases in the fraction of the TCP advertised receive window space in use for a single, long-lived connection.
以前のセクションでは、TCPがRSTスプーフィング攻撃に対する脆弱性によるBGPに対する最近の攻撃の性質について説明しました。これは、主に、宣伝されているTCPの割合の最近の増加が、単一の長寿命の接続に使用されているウィンドウスペースを受信します。
TCP currently authenticates received RSTs using the address and port pair numbers, and checks that the sequence number is inside the valid receiver window. The previous section demonstrated how TCP has become more vulnerable to RST spoofing attacks due to the increases in the receive window size. There are a number of current and proposed solutions to this vulnerability, all attempting to provide evidence that a received RST is legitimate.
TCPは現在、アドレスとポートペアの番号を使用して受信したRSTSを認証し、シーケンス番号が有効なレシーバーウィンドウ内にあることを確認しています。前のセクションでは、受信ウィンドウサイズの増加により、TCPが最初のスプーフィング攻撃に対してどのように脆弱になったかを示しました。この脆弱性に対する多くの現在および提案された解決策があり、すべてが受け取ったRSTが合法であるという証拠を提供しようとしています。
The transport layer represents the last place that segments can be authenticated before they affect connection management. TCP has a variety of current and proposed mechanisms to increase the authentication of segments, protecting against both off-path and on-path third-party spoofing attacks. Other transport protocols, such as SCTP and DCCP, also have limited antispoofing mechanisms.
輸送層は、接続管理に影響を与える前にセグメントを認証できる最後の場所を表します。TCPには、セグメントの認証を増やすためのさまざまな電流および提案されたメカニズムがあり、オフパスとパスのサードパーティのスプーフィング攻撃の両方から保護しています。SCTPやDCCPなどの他の輸送プロトコルにも、防腐剤のメカニズムが限られています。
An extension to TCP supporting MD5 authentication was developed in 1998 specifically to authenticate BGP connections (although it can be used for any TCP connection) [20]. The extension relies on a pre-shared secret key to authenticate the entire TCP segment, including the data, TCP header, and TCP pseudo-header (certain fields of the IP header). All segments are protected, including RSTs, to be accepted only when their signature matches. This option, although widely deployed in Internet routers, is considered undeployable for widespread use because the need for pre-shared keys [3][30]. It further is considered computationally expensive for either hosts or routers due to the overhead of MD5 [43][44].
MD5認証をサポートするTCPの拡張は、1998年にBGP接続を認証するために開発されました（ただし、TCP接続に使用できますが）[20]。拡張機能は、データ、TCPヘッダー、TCP擬似ヘッダー（IPヘッダーの特定のフィールド）を含むTCPセグメント全体を認証するために、事前に共有された秘密鍵に依存しています。RSTを含むすべてのセグメントは、署名が一致する場合にのみ受け入れられるように保護されています。このオプションは、インターネットルーターに広く展開されていますが、事前に共有キーの必要性が必要なため、広範囲にわたる使用のために展開できないと考えられています[3] [30]。さらに、MD5 [43] [44]のオーバーヘッドにより、ホストまたはルーターのいずれかで計算上高価であると考えられています。
There are also concerns about the use of MD5 due to recent collision-based attacks [22]. Similar concerns exist for SHA-1, and the IETF is currently evaluating how these attacks impact the recommendation for using these hashes, both in TCP/MD5 and in the IPsec suite. For the purposes of this discussion, the particular algorithm used in either protocol suite is not the focus, and there is ongoing work to allow TCP/MD5 to evolve to a more general TCP security option [6][47].
最近の衝突ベースの攻撃によるMD5の使用に関する懸念もあります[22]。SHA-1にも同様の懸念が存在し、IETFは現在、これらの攻撃がTCP/MD5とIPSECスイートの両方でこれらのハッシュを使用するための推奨にどのように影響するかを評価しています。この議論の目的のために、いずれかのプロトコルスイートで使用される特定のアルゴリズムは焦点ではなく、TCP/MD5がより一般的なTCPセキュリティオプション[6] [47]に進化できるようにするための継続的な作業があります。
A recent proposal extends TCP to further constrain received RST to match the expected next sequence number [36]. This restores TCP's resistance to spurious RSTs, effectively limiting the receive window for RSTs to a single number. As a result, an attacker would need to send 2^32 different packets to brute-force guess the sequence number (worst case, the average would be half that); this makes TCP's vulnerability to attack independent of the size of the receive window (RCV.WND). The extension further modifies the RST receiver to react to incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST source is legitimate, upon receipt of an ACK, the closed source would presumably emit a RST with the sequence number matching the ACK, correctly resetting the intended recipient. This modification changes TCP's control processing, adding to its complexity and thus potentially affecting its correctness (in contrast to adding MD5 signatures, which is orthogonal to TCP control processing altogether). For example, there may be complications between RSTs of different connections between the same pair of endpoints because RSTs flush the TIME-WAIT (as mentioned earlier). Further, this proposal modifies TCP so that, under some circumstances, a RST causes a reply (an ACK), in violation of generally accepted practice, if not gentle recommendation -- although this can be omitted, allowing timeouts to suffice. The advantage to this proposal is that it can be deployed incrementally and has benefit to the endpoint on which it is deployed. The other advantage to this proposal is that the window attenuation described here makes the vulnerability to spoofed RST packets independent of the size of the receive window.
最近の提案では、TCPを拡張して、予想される次のシーケンス番号[36]と一致するように、最初に受け取ったRをさらに制約しています。これにより、TCPのスプリアスRSTに対する抵抗が復元され、RSTSの受信ウィンドウが1つの数値に効果的に制限されます。その結果、攻撃者は2^32の異なるパケットを送信してブルートフォースを推測する必要があります（最悪の場合、平均は半分になります）。これにより、受信ウィンドウ（RCV.WND）のサイズとは無関係に攻撃に対するTCPの脆弱性が生じます。拡張機能は、ゼロ長さのACKを送信することにより、RSTレシーバーをさらに変更して、誤って数のRSTSに反応します。最初のソースが合法である場合、ACKを受信すると、閉じたソースは、ACKと一致するシーケンス番号を使用してRSTを放出し、意図した受信者を正しくリセットします。この変更は、TCPの制御処理を変更し、その複雑さを増し、その正確性に潜在的に影響を及ぼします（MD5署名の追加とは対照的に、これはTCPコントロール処理の直交である）。たとえば、RSTSがタイムウェイトをフラッシュするため、同じエンドポイントのペア間で異なる接続のRST間に合併症がある場合があります（前述のように）。さらに、この提案はTCPを修正するため、状況によっては、最初に返信（ACK）を引き起こし、穏やかな推奨ではないにしても一般的に受け入れられている実践に違反していますが、これは省略でき、タイムアウトが十分になります。この提案の利点は、段階的に展開できることであり、展開されているエンドポイントに利益をもたらすことです。この提案のもう1つの利点は、ここで説明するウィンドウの減衰により、受信ウィンドウのサイズとは無関係にスプーフィングされたRSTパケットに対する脆弱性があることです。
A variant of this proposal uses a different value to attenuate the window of viable RSTs. It requires RSTs to carry the initial sequence number rather than the next expected sequence number, i.e., the value negotiated on connection establishment [42][49]. This proposal has the advantage of using an explicitly negotiated value, but at the cost of changing the behavior of an unmodified endpoint to a currently valid RST. It would thus be more difficult, without additional mechanism, to deploy incrementally.
この提案のバリアントは、異なる値を使用して、実行可能なRSTのウィンドウを減衰させます。RSTは、次の予想されるシーケンス番号、つまり接続確立でネゴシエートされた値[42] [49]ではなく、初期シーケンス番号を運ぶ必要があります。この提案には、明示的に交渉された価値を使用するという利点がありますが、変更されていないエンドポイントの動作を現在有効なRSTに変更するという犠牲を払っています。したがって、追加のメカニズムがなければ、段階的に展開することはより困難です。
Another variant of this proposal involves increasing TCP's window space, rather than decreasing the valid range for RSTs, i.e., increasing the sequence space from 32 bits to 64 bits. This has the equivalent effect -- the ratio of the valid sequence numbers for any segment to the overall sequence number space is significantly reduced. The use of the larger space, as with current schemes to establish weak authentication using initial sequence numbers (ISNs), is contingent on using suitably random values for the ISN. Such randomness adds additional complexity to TCP both in specification and implementation, and provides only very weak authentication. Such a modification is not obviously backward compatible, and would be thus difficult to deploy.
この提案のもう1つのバリアントは、RSTの有効な範囲を減らすのではなく、TCPのウィンドウスペースを増加させること、つまり32ビットから64ビットから64ビットから64ビットを増加させることです。これには同等の効果があります - 任意のセグメントの有効なシーケンス番号の比率全体に対するシーケンス番号スペースの比率は大幅に減少します。初期シーケンス番号（ISN）を使用して弱い認証を確立するための現在のスキームと同様に、より大きなスペースの使用は、ISNに適切にランダムな値を使用することを条件としています。このようなランダム性は、仕様と実装の両方でTCPに追加の複雑さを追加し、非常に弱い認証のみを提供します。このような変更は明らかに後方互換性がないため、展開することは困難です。
A converse variant of increasing TCP's window space is to decrease the receive window (RCV.WND) explicitly, which would further reduce the effectiveness of spoofed RSTs with random sequence numbers. This alternative may reduce the throughput of the connection, if the advertised receive window is smaller than the bandwidth-delay product of the connection.
TCPのウィンドウスペースの増加の逆変異体は、受信ウィンドウ（RCV.WND）を明示的に減らすことであり、ランダムシーケンス番号でスプーフィングされたRSTSの有効性をさらに低下させます。この代替手段は、接続された受信ウィンドウが接続の帯域幅遅延積よりも小さい場合、接続のスループットを減らす可能性があります。
Another way to authenticate TCP segments is via its timestamp option, using the value as a sort of authentication [34]. This requires that the receiver TCP discard segments whose timestamp is outside the accepted window, which is derived from the timestamps of other packets from the same connection. This technique uses an existing TCP option, but also requires modified TCP control processing (with the same caveats) and may be difficult to deploy incrementally without further modifications. Additionally, the timestamp value may be easier to guess because it can be derived predictably, either assuming it represents actual time at the host, or by probing the host using unrelated benign traffic.
TCPセグメントを認証する別の方法は、その値を一種の認証として使用して、そのタイムスタンプオプションを使用することです[34]。これには、レシーバーTCPが、タイムスタンプが受け入れられているウィンドウの外側にあるセグメントを破棄する必要があります。これは、同じ接続からの他のパケットのタイムスタンプから派生しています。この手法では、既存のTCPオプションを使用しますが、変更されたTCP制御処理（同じ警告）も必要であり、さらに変更することなく段階的に展開することは困難な場合があります。さらに、タイムスタンプの値は、ホストでの実際の時間を表すと仮定するか、無関係の良性トラフィックを使用してホストを調査することにより、予測可能に導出できるため、推測が容易になる場合があります。
All of the above techniques are variants of cookies, otherwise meaningless data whose value is used to validate the packet. In the case of MD5 checksums, the cookie is computed based on a shared secret. Note that even a signature can be guessed, and presents a 1 in 2^(signature length) probability of attack. The primary difference is that MD5 signatures are effectively one-time cookies, not predictable based on on-path snooping, because they are dependent on packet data and thus do not repeat. Window attenuation sequence numbers can be guessed by snooping the sequence number of current packets of an existing connection, and timestamps can be guessed even less directly, either by separate benign connections or by assuming they roughly correlate to local time. These variants of cookies are similar in spirit to TCP SYN cookies, again patching a vulnerability to off-path third-party spoofing attacks based on a (fairly weak, excepting MD5) form of authentication. Another form of cookie is the source port itself, which can be randomized but provides only 16 bits of protection (65,000 combinations), which may be exhaustively attacked. This can be combined with destination port randomization as well, but that would require a separate coordination mechanism (so both parties know which ports to use), which is equivalent to (and as infeasible for large-scale deployments as) exchanging a shared secret [39].
上記の手法はすべてCookieのバリエーションであり、それ以外の場合は、パケットの検証に値が使用される意味のないデータです。MD5チェックサムの場合、Cookieは共有された秘密に基づいて計算されます。署名でさえ推測できることに注意し、2^（署名長）攻撃の確率1を提示することに注意してください。主な違いは、MD5の署名が効果的に1回限りのCookieであり、パケットデータに依存しているため繰り返されないため、オンパススヌープに基づいて予測できないことです。ウィンドウの減衰シーケンス番号は、既存の接続の現在のパケットのシーケンス数をスヌーピングすることで推測できます。また、タイムスタンプは、別々の良性接続または現地時間と大まかに相関すると仮定することにより、さらに直接推測できません。これらのCookieのバリアントは、TCP Syn Cookieとスピリットが類似しており、再び（MD5を除く）認証形態に基づいて、オフパスのサードパーティのスプーフィング攻撃に対する脆弱性にパッチを当てます。Cookieの別の形式はソースポート自体です。これはランダム化できますが、16ビットの保護（65,000の組み合わせ）しか提供されていないため、徹底的に攻撃される可能性があります。これは宛先ポートランダム化とも組み合わせることができますが、それは別の調整メカニズム（両方の当事者が使用するポートを知っている）が必要です。39]。
The analysis of the potential for RST spoofing above assumes that the advertised receive window is opened to the maximum extent suggested by the bandwidth-delay product of the end-to-end path, and that the window is opened to an appreciable fraction of the overall sequence number space. As noted earlier, for most common cases, connections are too brief or over bandwidths too low for such a large window to be useful. Expanding TCP's sequence number space is a direct way to further avoid such vulnerability, even for long connections over emerging bandwidths. If either manual tuning or automatic tuning of the advertised receive window (via receive buffer tuning) is not provided, this is not an issue (although connection performance will suffer) [38].
上記の最初のスプーフィングの可能性の分析は、広告された受信ウィンドウがエンドツーエンドパスの帯域幅遅延積によって提案された最大範囲で開かれ、ウィンドウが全体のかなりの部分に開かれていることを前提としています。シーケンス番号スペース。前述のように、ほとんどの一般的なケースでは、接続が短すぎるか、帯域幅が低すぎて、このような大きなウィンドウが役立つには低すぎます。TCPのシーケンス番号スペースを拡大することは、新たな帯域幅をめぐる長いつながりであっても、このような脆弱性をさらに回避するための直接的な方法です。広告された受信ウィンドウの手動チューニングまたは自動チューニング（受信バッファチューニングを介して）が提供されていない場合、これは問題ではありません（接続性能は低下します）[38]。
It may be sufficient for the endpoint to limit the advertised receive window by deliberately leaving it small. If the receive socket buffer is limited, e.g., to the ubiquitous default of 64 KB, the advertised receive window will not be as vulnerable even for very long connections over very high bandwidths. The vulnerability will grow linearly with the increased network speed, but not as the square. The consequence is lower sustained throughput, where only one window's worth of data per round-trip time (RTT) is exchanged.
エンドポイントが故意に小さいままにしておくことにより、宣伝された受信ウィンドウを制限するだけで十分かもしれません。受信ソケットバッファーが限られている場合、たとえば64 kbのユビキタスなデフォルトに制限されている場合、広告された受信ウィンドウは、非常に高い帯域幅にわたる非常に長い接続でも脆弱ではありません。脆弱性は、ネットワーク速度の向上とともに直線的に成長しますが、正方形としてではありません。結果は、往復時間（RTT）ごとに1つのウィンドウのデータのみが交換される、1つのウィンドウのデータのみが交換されます。
This will keep the connection open longer; for long-lived connections with continuous sourced data, this may continue to present an attack opportunity, albeit a sparse and slow-moving target. For the most recent case where BGP data is being exchanged between Internet routers, the data is bursty and the aggregate traffic may be small (i.e., unlikely to cover a substantial portion of the sequence space, even if long-lived), so smaller advertised receive windows (via small receiver buffers) may, in some cases, sufficiently address the immediate problem. This assumes that the routing tables can be exchanged quickly enough with bandwidth reduced due to the smaller buffers, or perhaps that the advertised receive window is opened only during a large burst exchange (e.g., via some other signal between the two routers, or a time-based signal, though either would be nonstandard).
これにより、接続が長く開いたままになります。連続したソースデータとの長寿命の接続の場合、これはまばらで遅いターゲットではありますが、引き続き攻撃の機会を提示し続ける可能性があります。BGPデータがインターネットルーター間で交換されている最新のケースでは、データが破裂し、集計トラフィックが少ない場合があります（つまり、長寿命であっても、シーケンススペースのかなりの部分をカバーする可能性は低い）、宣伝が小さい（小さなレシーバーバッファを介して）Windowsを受け取ることができますが、場合によっては、当面の問題に十分に対処することができます。これは、バッファーが小さいために帯域幅を縮小して十分に迅速に交換できるか、または大規模なバースト交換中に広告された受信ウィンドウが開くことができることを前提としています（たとえば、2つのルーターまたは時間の間の他の信号を介して、 - ベースの信号は、どちらも非標準です）。
Segment authentication has been addressed at the transport layer in other protocols. Both SCTP and DCCP include cookies for connection establishment and use them to authenticate a variety of other control messages [28][41]. The inclusion of such mechanism at the transport protocol, although emerging as standard practice, complicates the design and implementation of new protocols [32]. As new attacks are discovered (SYN floods, RSTs, etc.), each protocol must be modified individually to compensate. A network solution may be more appropriate and efficient.
セグメント認証は、他のプロトコルの輸送層で対処されています。SCTPとDCCPの両方に接続確立のCookieが含まれており、それらを使用して他のさまざまな制御メッセージを認証します[28] [41]。輸送プロトコルにそのようなメカニズムを含めることは、標準的な実践として出現していますが、新しいプロトコルの設計と実装を複雑にします[32]。新しい攻撃が発見されると（Syn洪水、RSTなど）、各プロトコルを補償するために個別に変更する必要があります。ネットワークソリューションは、より適切かつ効率的になる場合があります。
It should be noted that RST attacks, which rely on brute-force, are relatively easy for intrusion detection software to detect at the TCP layer. Any connection that receives a large number of invalid -- outside-window -- RSTs might have subsequent RSTs blocked, to defeat such attacks. This would have the side-effect of blocking legitimate RSTs to that connection, which might then interfere with cleaning up the transport state between the endpoint peers. This side-effect, coupled with the increased monitoring load, might render such solutions undesirable in the general case, but they might usefully be applied to special cases, e.g., for BGP for routers.
ブルートフォースに依存しているRST攻撃は、侵入検知ソフトウェアがTCP層で検出するのが比較的簡単であることに注意する必要があります。多数の無効な接続（外部ウィンドウ）のRSTが、そのような攻撃を打ち負かすために、その後のRSTSがブロックされた可能性があります。これは、その接続に対して正当なRSTSをブロックするという副作用があり、それがエンドポイントピア間の輸送状態のクリーンアップを妨げる可能性があります。この副作用は、モニタリング負荷の増加と相まって、一般的なケースではそのようなソリューションを望ましくない場合がありますが、例えばルーターのBGPの場合、特別なケースに有用に適用される可能性があります。
There are two primary variants of network layer solutions to spoofing: address filtering and IPsec. Address filtering is an indirect system that relies on other parties to filter packets sent upstream of an attack, but does not necessarily require participation of the packet source. IPsec requires cooperation between the endpoints wanting to avoid attack on their connection, which currently involves preexisting shared knowledge of either a shared key or shared certificate authority.
スプーフィングには、ネットワークレイヤーソリューションには2つの主要なバリエーションがあります。アドレスフィルタリングとIPSECです。アドレスフィルタリングは、攻撃の上流に送られたパケットをフィルタリングするために他の関係者に依存する間接システムですが、必ずしもパケットソースの参加を必要としません。IPSECには、接続への攻撃を避けたいエンドポイント間の協力が必要です。これには、現在、共有キーまたは共有認証局のいずれかの既存の共有知識が含まれています。
Address filtering is often proposed as an alternative to protocol mechanisms to defeat IP source address spoofing [2][13]. Address filtering restricts traffic from downstream sources across transit networks based on the IP source address. A kind of filtering already occurs at the endpoints of a connection, because attack messages must match the socket pair to succeed; again, note that such attacks require knowing the entire socket pair, and are unlikely except in particular cases. This section discusses filtering based on address only, typically done at the borders of an AS.
アドレスフィルタリングは、IPソースアドレスのスプーフィング[2] [13]を打ち負かすためのプロトコルメカニズムの代替として提案されることがよくあります。アドレスフィルタリングは、IPソースアドレスに基づいて、トランジットネットワーク全体の下流のソースからのトラフィックを制限します。攻撃メッセージはソケットペアを一致させて成功する必要があるため、接続のエンドポイントで既にフィルタリングの一種が発生しています。繰り返しますが、そのような攻撃ではソケットペア全体を知る必要があり、特にケースを除いて可能性は低いことに注意してください。このセクションでは、通常、ASの境界で行われるアドレスのみに基づいてフィルタリングについて説明します。
It can also restrict core-to-edge paths to reject traffic that should have originated further toward the edge. It cannot restrict traffic from edges lacking filtering through the core to a particular edge. As a result, each border router must perform the appropriate filtering for overall protection to result; failure of any border router to filter defeats the protection of all participants inside the border, and potentially those outside as well. Address filtering at the border can protect those inside the border from some kinds of spoofing, i.e., connections among those inside a border, because only interior addresses should originate inside the border. It cannot, however, protect connections including endpoints outside the border (i.e., those that traverse the AS boundary) except to restrict where the traffic enters from, e.g., if it expected from one AS and not another.
また、コアからエッジへのパスを制限して、エッジに向かってさらに発生するはずのトラフィックを拒否することもできます。コアを介して特定のエッジまでのフィルタリングを欠いているエッジからトラフィックを制限することはできません。その結果、各ボーダールーターは、全体的な保護を結果として得るために適切なフィルタリングを実行する必要があります。ボーダールーターのフィルターの失敗は、国境内のすべての参加者の保護、および潜在的に外部の参加者の保護を打ち負かします。国境でのアドレスフィルタリングは、国境内の人が何らかのスプーフィングから保護できます。つまり、境界内の住所のみが国境内で発生する必要があるため、境界内の人々の間のつながりから保護できます。ただし、境界外のエンドポイントを含む接続（つまり、境界として境界を横断するもの）を含む接続を保護することはできません。
As a result, address filtering is not a local solution that can be deployed to protect communicating pairs, but rather relies on a distributed infrastructure of trusted gateways filtering forged traffic where it enters the network. It is not feasible for local, incremental deployment, but may be applicable to connections among those inside the protected border in some scenarios. Applying filtering can also be useful to reduce the network load of spoofed traffic [31].
その結果、アドレスフィルタリングは、通信ペアを保護するために展開できるローカルソリューションではなく、ネットワークに入る場所に鍛造トラフィックをフィルタリングする信頼できるゲートウェイの分散インフラストラクチャに依存しています。ローカルの増分展開では実行可能ではありませんが、一部のシナリオでは、保護された国境内の接続に適用できる場合があります。フィルタリングの適用は、スプーフィングされたトラフィックのネットワーク負荷を減らすのにも役立ちます[31]。
A more recent variant of address filtering checks the IP TTL (Time to Live) field, relying on the TTL set by the other end of the connection [15]. This technique has been used to provide filtering for BGP. It assumes the connection source TTL is set to 255; packets at the receiver are checked for TTL=255, and others are dropped. This restricts traffic to one hop upstream of the receiver (i.e., a BGP router), but those hops could include other user programs at those nodes (e.g., the BGP router's peer) or any traffic those nodes accept via tunnels -- because tunnels need not decrement TTLs, notably for "bump in the wire" (BITW) or BITW-equivalent scenarios [33] (see also Section 5.1 of [15] and [16]). TTL filtering works only where all traffic from the other end of the tunnel is trusted, i.e., where it does not originate or transit spoofed traffic. The use of TTL rather than link or network security also assumes an untampered point-to-point link, where no other traffic can be spoofed onto a link.
より最近のアドレスフィルタリングのバリアントは、接続のもう一方の端によって設定されたTTLに依存して、IP TTL（Live to Live）フィールドをチェックします[15]。この手法は、BGPのフィルタリングを提供するために使用されています。接続ソースTTLが255に設定されていると想定しています。受信機のパケットはTTL = 255をチェックし、その他はドロップされます。これにより、トラフィックがレシーバーの上流（つまり、BGPルーター）の1つのホップへのトラフィックを制限しますが、これらのホップには、これらのノード（例：BGPルーターのピア）またはトンネルを介して受け入れるトラフィックの他のユーザープログラムを含めることができます - トンネルが必要なため特に「ワイヤーのバンプ」（BITW）またはBITWに相当するシナリオ[33]の場合は、TTLを減少させません（[15]および[16]のセクション5.1も参照）。TTLフィルタリングは、トンネルの反対側からのすべてのトラフィックが信頼されている場合にのみ機能します。つまり、スプーフィングされたトラフィックを発生または通過しない場合です。リンクやネットワークのセキュリティではなくTTLの使用は、アンペアのないポイントツーポイントリンクも想定しています。
This method of filtering works best where traffic originates one hop away, so that the address filtering is based on the trust of only directly-connected (tunneled or otherwise) nodes. Like conventional address filtering, this reduces spoofing traffic in general, but is not considered a reliable security mechanism because it relies on distributed filtering (e.g., the fact that upstream nodes do not terminate tunnels arbitrarily).
このフィルタリングの方法は、トラフィックが1つのホップアウェイを発信する場合に最適に機能するため、アドレスフィルタリングは直接接続された（トンネルまたはその他の）ノードのみの信頼に基づいています。従来のアドレスフィルタリングと同様に、これにより一般的なスプーフィングトラフィックが減少しますが、分散フィルタリングに依存するため、信頼できるセキュリティメカニズムとは見なされません（たとえば、上流ノードが任意にトンネルを終了しないという事実）。
TCP is susceptible to RSTs, but also to other off-path and on-path spoofing attacks, including SYN attacks. Other transport protocols, such as UDP and RTP are equally susceptible. Although emerging transport protocols attempt to defeat such attacks at the transport layer, such attacks take advantage of network layer identity spoofing. The packet is coming from an endpoint that is spoofing another endpoint, either upstream or somewhere else in the Internet. IPsec was designed specifically to establish and enforce authentication of a packet's source and contents in order to most directly and explicitly address this security vulnerability.
TCPは、RSTSの影響を受けやすいだけでなく、Syn攻撃を含む他のオフパスおよびパス上のスポーフ攻撃にも影響を与えます。UDPやRTPなどの他の輸送プロトコルは同様に影響を受けやすいです。新興輸送プロトコルは、輸送層でのそのような攻撃を打ち負かしようとしますが、そのような攻撃はネットワーク層のアイデンティティスプーフィングを利用します。このパケットは、上流またはインターネットのどこかで別のエンドポイントをスプーフィングしているエンドポイントから来ています。IPSECは、このセキュリティの脆弱性に最も直接的かつ明示的に対処するために、パケットのソースとコンテンツの認証を確立および実施するために特別に設計されました。
The larger problem with IPsec is that of key distribution and use. IPsec is often cumbersome, and has only recently been supported in many end-system operating systems. More importantly, it relies on preshared keys, signed X.509 certificates, or a trusted third-party (e.g., Kerberos) key infrastructure to establish and exchange keying information (e.g., via IKE). Each of these issues presents challenges when using IPsec to secure traffic to a well-known server, whose clients may not support IPsec or may not have registered with a previously-known certificate authority (CA).
IPSECのより大きな問題は、重要な分布と使用の問題です。IPSECはしばしば面倒であり、最近の多くの最終システムオペレーティングシステムでサポートされています。さらに重要なことは、それはX.509証明書に署名されたPresharedキー、または信頼できるサードパーティ（たとえば、Kerberos）の重要なインフラストラクチャに依存して、キー情報を確立および交換する（例：IKEを介して）。これらの各問題は、IPSECを使用して有名なサーバーへのトラフィックを保護する場合の課題を提示します。
These keying challenges are being addressed in the IETF in ways that will enable servers secure associations with other parties without advance coordination [45][46]. This can be especially useful for publicly-available servers, or for protecting connections to servers that -- for whatever reason -- have not or will not deploy conventional IPsec certificates (i.e., core Internet BGP routers).
これらのキーイングの課題は、事前調整なしにサーバーが他の関係者との関連性を確保できるようにする方法でIETFで対処されています[45] [46]。これは、公開されているサーバーや、何らかの理由で、従来のIPSEC証明書（コアインターネットBGPルーター）を展開していない、または展開していないサーバーへの接続を保護するために特に役立ちます。
Just as spoofed TCP packets can terminate a connection, so too can spoofed ICMP packets. ICMP can be used to launch a variety of attacks on TCP including connection resets, path-MTU attacks, and can also be used to attack the host with non-TCP 'ping of death' and 'smurf attacks', etc. [40]. ICMP thus represents a substantial threat to TCP, but this is not the focus of this document, although a number of protections are discussed below because some are comparable to TCP anti-spoofing techniques. Note also that ICMP attacks on TCP assume that the socket pair is known by the attacker, which is unlikely except for a subset of services between pairs of widely-known endpoints.
スプーフィングされたTCPパケットが接続を終了できるように、ICMPパケットをスプーフィングすることもできます。ICMPは、接続リセット、Path-MTU攻撃など、TCPに対するさまざまな攻撃を開始するために使用できます。また、非TCP「Ping of Death」および「Smurf Attacks」などでホストを攻撃するためにも使用できます[40]。したがって、ICMPはTCPに対する大きな脅威を表していますが、これはこのドキュメントの焦点ではありませんが、一部の保護はTCPアンチスポーフィング技術に匹敵するため、以下で多くの保護を説明します。また、TCPに対するICMP攻撃は、ソケットペアが攻撃者によって知られていると仮定していることに注意してください。これは、広く知られているエンドポイントのペア間のサービスのサブセットを除いてありそうもないことです。
TCP headers can be included inside certain ICMP messages [7]. There have been recent suggestions to validate the sequence number of TCP headers when they occur inside ICMP messages [18]. This sequence checking is similar to checks that would occur for conventional data packets in TCP, but is being proposed in the spirit of the RST window attenuation described in Section 3.1.2.
TCPヘッダーは、特定のICMPメッセージに含めることができます[7]。ICMPメッセージ内で発生する場合、TCPヘッダーのシーケンス数を検証するための最近の提案がありました[18]。このシーケンスチェックは、TCPの従来のデータパケットで発生するチェックに似ていますが、セクション3.1.2で説明されている最初のウィンドウ減衰の精神で提案されています。
Some such checks may be reasonable, especially where they parallel the validations already performed by TCP processing, notably where they emulate the semantics of such processing. For example, the TCP checksum should be validated (if the entire TCP segment is contained in the ICMP message) before any fields of the TCP header are examined, to avoid reacting to corrupted packets. Similarly, if the TCP MD5 option is present, its signature should probably be validated before considering the contents of the message. Such validation can ensure that the packet was not corrupted prior to the ICMP generation (checksum), that the packet was one sent by the source (IPsec or TCP/MD5 authenticated), or that the packet was not in the network for an excess of 2*MSL (valid sequence number).
このようなチェックの一部は、特にTCP処理によって既に実行されている検証、特にそのような処理のセマンティクスをエミュレートする場合に並行している場合に合理的なものになる場合があります。たとえば、TCPヘッダーのフィールドを調べる前に、TCPチェックサムを検証する必要があります（TCPセグメント全体がICMPメッセージに含まれている場合）。破損したパケットに反応しないようにします。同様に、TCP MD5オプションが存在する場合、メッセージの内容を検討する前に、おそらくその署名を検証する必要があります。このような検証は、ICMP生成の前にパケットが破損していないこと（チェックサム）、パケットがソースによって送信されたもの（IPSECまたはTCP/MD5認証）であること、またはパケットが過剰なネットワークにないことを保証できます。2*MSL（有効なシーケンス番号）。
ICMP presents a particular challenge because some messages can reset a connection more easily -- with less validation -- than even some spoofed TCP segments. One other proposed alternative is to change TCP's reaction to ICMPs after a connection is established; that may leave TCP susceptible during connection establishment and modifies TCP's reaction to certain valid network events [19]. This considers the context-sensitivity of ICMP messages, as does IPsec in some tunneled configurations, but the recommendations are ambiguous regarding such filtering [27].
ICMPは、一部のメッセージをスプーフィングしたTCPセグメントよりも、より簡単に検証をより簡単にリセットできるため、特定の課題を提示します。もう1つの提案された代替案は、接続が確立された後にTCPのICMPに対する反応を変更することです。これにより、接続の確立中にTCPが影響を受けやすく、特定の有効なネットワークイベントに対するTCPの反応を修正する可能性があります[19]。これは、一部のトンネル構成のIPSECと同様に、ICMPメッセージのコンテキスト感度を考慮しますが、そのようなフィルタリングに関して推奨事項はあいまいです[27]。
Ultimately, requiring TCP ICMP messages to be 'in window' may be insufficient protection, as this document shows for spoofed data. ICMP packets can be authenticated when originating at known, trusted endpoints, such as endpoints of connections or routers in known domains with preexisting IPsec associations. Unfortunately, they also can originate at other places in the network. In addition, some networks filter all ICMP packets because validation may not be possible, especially because they can be injected from anywhere in a network, and so cannot be easily and locally address filtered [27]. As a result, they are not addressed separately in the issues or security considerations of this document further.
最終的に、このドキュメントがスプーフィングされたデータに示すように、TCP ICMPメッセージを「ウィンドウ」にする必要がある場合は、保護が不十分な場合があります。ICMPパケットは、既存のIPSEC関連を持つ既知のドメインの接続のエンドポイントやルーターなど、既知の信頼できるエンドポイントで発信する場合、認証できます。残念ながら、彼らはネットワーク内の他の場所でも発生する可能性があります。さらに、一部のネットワークは、特にネットワーク内のどこからでも注入できるため、検証が不可能であるため、すべてのICMPパケットをフィルタリングします。その結果、このドキュメントの問題やセキュリティ上の考慮事項において、それらは別々に対処されていません。
There are a number of existing and proposed solutions addressing the vulnerability of transport protocols in general (and TCP in specific) to off-path third-party spoofing attacks. As shown, these operate at the transport or network layer. Transport solutions require separate modification of each transport protocol, addressing network identity spoofing separately in the context of each transport association. Network solutions require distributed coordination (filtering) or can be computationally intensive and require pervasive registration of certificate authorities with every possible endpoint (authentication). This section explains these observations further.
輸送プロトコルの脆弱性（および特定のTCP）に対処する多くの既存および提案されたソリューションがあります。示されているように、これらは輸送またはネットワーク層で動作します。輸送ソリューションでは、各輸送プロトコルの個別の変更が必要であり、各輸送協会のコンテキストでネットワークアイデンティティのスプーフィングに個別に対処する必要があります。ネットワークソリューションでは、分散調整（フィルタリング）が必要であるか、計算的に集中的であり、あらゆる可能なエンドポイント（認証）を持つ証明書当局の広範な登録が必要です。このセクションでは、これらの観察結果についてさらに説明します。
Transport solutions rely on shared cookies to authenticate segments, including data, transport header, and even pseudo-header (e.g., fixed portions of the outer IP header in TCP). Because the Internet relies on stateless network protocols, it makes sense to rely on state establishment and maintenance available in some transport layers not only for the connection but for authentication state. Three-way handshakes and heartbeats can be used to negotiate authentication state in conjunction with connection parameters, which can be stored with connection state easily.
トランスポートソリューションは、共有Cookieに依存して、データ、トランスポートヘッダー、さらには疑似ヘッダー（TCPの外側IPヘッダーの固定部分）などのセグメントを認証します。インターネットはStateless Network Protocolsに依存しているため、接続だけでなく認証状態のために、一部の輸送層で利用可能な州の確立とメンテナンスに依存することは理にかなっています。3方向のハンドシェイクとハートビートを使用して、接続パラメーターと組み合わせて認証状態を交渉します。これは、接続状態に簡単に保存できます。
As noted earlier, transport layer solutions require separate modification of all transport protocols to include authentication. Not all transport protocols support negotiated endpoint state (e.g., UDP), and legacy protocols have been notoriously difficult to safely augment. Not all authentication solutions are created equal, either, and relying on a variety of transport solutions exposes end-systems to increased potential for incorrectly specified or implemented solutions. Transport authentication has often been developed piece-wise, in response to specific attacks, e.g., SYN cookies and RST window attenuation [4][36].
前述のように、輸送層ソリューションでは、認証を含めるためにすべての輸送プロトコルの個別の変更が必要です。すべての輸送プロトコルがネゴシエートされたエンドポイント状態（UDPなど）をサポートしているわけではなく、レガシープロトコルが安全に拡大するのが難しいことで有名です。すべての認証ソリューションが平等に作成されているわけではなく、さまざまな輸送ソリューションに依存することで、最終システムが誤って指定または実装されたソリューションの可能性の増加にさらされます。輸送認証は、特定の攻撃、たとえばSyn CookieやRSTウィンドウの減衰に応じて、しばしば部分的に開発されてきました[4] [36]。
Transport layer solutions are not only per-protocol, but often per-connection. This has both advantages and drawbacks. One advantage to transport layer solutions is that they can protect the transport protocol when lower layers have failed, e.g., due to bugs in implementation. TCP already includes a variety of packet validation mechanisms to protect in these cases, e.g., checking that RSTs are in-window. More strict checks can increase the protections provided, e.g., to protect against misaddressed RSTs that end up in-window (via TCPsecure) or to protect against connection interruption due to RSTs, SYNs, or data injection from misaddressed packets (TCP/MD5) [36].
輸送層ソリューションは、プロトコルごとであるだけでなく、接続ごとにしばしばあります。これには利点と欠点の両方があります。輸送層ソリューションの利点の1つは、実装のバグにより、下層層が失敗したときに輸送プロトコルを保護できることです。TCPには、これらのケースで保護するためのさまざまなパケット検証メカニズムが既に含まれています。たとえば、RSTがウィンドウ内であることを確認してください。より厳格なチェックは、たとえば、ウィンドウ内（TCPSEcureを介して）になった誤解されたRSTから保護するために提供された保護を増やすことができます。36]。
Another advantage is that transport layer protections can be more specifically limited to a particular connection. Because each connection negotiates its state separately, that state can be more specifically tied to that connection. This is both an advantage and a drawback. It can make it easier to tie security to an individual connection, although in practice a shared secret or certificate will generally be shared across multiple connections.
もう1つの利点は、輸送層の保護が特定の接続により具体的に制限される可能性があることです。各接続はその状態を個別に交渉しているため、その状態はその接続により具体的に結び付けられます。これは利点と欠点の両方です。セキュリティを個々の接続に容易にすることができますが、実際には共有された秘密または証明書が一般に複数の接続で共有されます。
As a drawback, each transport connection needs to negotiate and maintain authentication state separately. Some overhead is not amortized over multiple connections, e.g., overheads in packet exchanges, whereas other overheads are not amortized over different transport protocols, e.g., design and implementation complexity -- both as would be the case in a network layer solution. Because the authentication happens later in packet processing than is required, additional endpoint resources may be needlessly consumed, e.g., in demultiplexing received packets, indexing connection identifiers, and continuing to buffer spoofed packets, etc., only to be dropped later at the transport layer.
欠点として、各輸送接続は、認証状態を個別に交渉し、維持する必要があります。一部のオーバーヘッドは、複数の接続、たとえばパケット交換のオーバーヘッドで償却されませんが、他のオーバーヘッドは、ネットワークレイヤーソリューションの場合と同様に、異なる輸送プロトコル、例えば設計と実装の複雑さで償却されません。認証はパケット処理の後半で必要以上に行われるため、追加のエンドポイントリソースが不必要に消費される場合があります。たとえば、受信したパケット、インデックス作成接続識別子のインデックス作成、およびスプーフィングされたパケットなどを継続することで、輸送層で後でドロップされます。。
A network layer solution avoids the hazards of multiple transport variants, using a single shared endpoint authentication mechanism early in receiver packet processing to discard unauthenticated packets at the network layer instead. This defeats spoofing entirely because spoofing involves masquerading as another endpoint, and network layer security validates the endpoint as the source of the packets it emits. Such a network level solution protects all transport protocols as a result, including both legacy and emerging protocols, and reduces the complexity of these protocols as well. A shared solution also reduces protocol overhead, and decouples the management (and refreshing) of authentication state from that of individual transport connections. Finally, a network layer solution protects not only the transport layer but the network layer as well, e.g., from IGMP, and some kinds of ICMP (Section 4), spoofing attacks.
ネットワークレイヤーソリューションは、複数のトランスポートバリアントの危険性を回避します。これは、レシーバーパケット処理の初期に単一の共有エンドポイント認証メカニズムを使用して、代わりにネットワークレイヤーで認定されていないパケットを破棄します。これは、スプーフィングが別のエンドポイントを装って装飾することを伴い、ネットワークレイヤーセキュリティがエンドポイントを放出するパケットのソースとして検証するため、スプーフィングを完全に打ち負かします。このようなネットワークレベルのソリューションは、レガシーと新興プロトコルの両方を含む結果として、すべての輸送プロトコルを保護し、これらのプロトコルの複雑さも削減します。共有ソリューションは、プロトコルオーバーヘッドも削減し、認証状態の管理（および更新）を個々の輸送接続の状態から切り離します。最後に、ネットワークレイヤーソリューションは、輸送層だけでなく、IGMPやある種のICMP（セクション4）からのネットワーク層も、スプーフィング攻撃を保護します。
The IETF Proposed Standard protocol for network layer authentication is IPsec [27]. IPsec specifies the overall architecture, including header authentication (AH) [25] and encapsulation (ESP) modes [26].
ネットワークレイヤー認証用の標準プロトコルを提案するIETFはIPSECです[27]。IPSECは、ヘッダー認証（AH）[25]やカプセル化（ESP）モード[26]を含む全体的なアーキテクチャを指定します。
AH authenticates both the IP header and IP data, whereas ESP authenticates only the IP data (e.g., transport header and payload). AH is being phased out since ESP is more efficient and the Security Parameters Index (SPI) includes sufficient information to verify the IP header anyway [27]. These two modes describe the security applied to individual packets within the IPsec system; key exchange and management is performed either out-of-band (via pre-shared keys) or by an automated key exchange protocol, e.g., IKE [24].
AHはIPヘッダーとIPデータの両方を認証しますが、ESPはIPデータのみを認証します（たとえば、トランスポートヘッダーとペイロード）。ESPがより効率的であり、セキュリティパラメータインデックス（SPI）にはとにかくIPヘッダーを検証するのに十分な情報が含まれているため、AHは段階的に廃止されています[27]。これらの2つのモードは、IPSECシステム内の個々のパケットに適用されるセキュリティを説明しています。主要な交換と管理は、帯域外（事前共有キーを介して）または自動化されたキー交換プロトコル、例えばIKE [24]によって実行されます。
IPsec already provides authentication of an IP header and its data contents sufficient to defeat both on-path and off-path third-party spoofing attacks. IKE can configure authentication between two endpoints on a per-endpoint, per-protocol, or per-connection basis, as desired. IKE also can perform automatic periodic re-keying, further defeating crypto-analysis based on snooping (clandestine data collection). The use of IPsec is already commonly strongly recommended for protected infrastructure.
IPSECはすでに、IPヘッダーと、オンパスとオフパスの両方のサードパーティのスプーフィング攻撃の両方を打ち負かすのに十分なデータコンテンツの認証を提供しています。IKEは、必要に応じて、エンドポイント、プロトコルごと、または接続ごとの2つのエンドポイント間で認証を構成できます。Ikeはまた、自動的に周期的な再キーを実行し、スヌーピングに基づいて暗号分析をさらに打ち負かすことができます（秘密のデータ収集）。IPSECの使用は、保護されたインフラストラクチャに一般的に一般的に強く推奨されています。
Existing IPsec is not appropriate for many deployments. It is computationally intensive both in key management and individual packet authentication [43]. This computational overhead can be prohibitive, and so often requires additional hardware, especially in commercial routers. As importantly, IKE is not anonymous; keys can be exchanged between parties only if they trust each other's X.509 certificates, trust some other third-party to help with key generation (e.g., Kerberos), or pre-share a key. These certificates provide identification (the other party knows who you are) only where the certificates themselves are signed by certificate authorities (CAs) that both parties already trust. To a large extent, the CAs themselves are the pre-shared keys that help IKE establish security association keys, which are then used in the authentication algorithms.
既存のIPSECは、多くの展開には適していません。これは、主要な管理と個々のパケット認証の両方で計算的に集中しています[43]。この計算オーバーヘッドは法外なものである可能性があるため、特に市販のルーターでは追加のハードウェアが必要です。重要なこととして、Ikeは匿名ではありません。キーは、お互いのX.509証明書を信頼している場合にのみ、当事者間で交換できます。他のサードパーティを信頼してキー生成（Kerberosなど）を支援するか、キーをプレシェアすることができます。これらの証明書は、証明書自体が証明書当局（CAS）によって署名されている場合にのみ識別（あなたが誰であるかを知っています）を提供します。大部分は、CAS自体が、IKEがセキュリティアソシエーションキーを確立するのに役立つ事前共有キーであり、それが認証アルゴリズムで使用されます。
Alternative mechanisms are under development to address this limitation, to allow publicly-accessible servers to secure connections to clients not known in advance, or to allow unilateral relaxation of identity validation so that the remaining protections of IPsec can be made available [45][46]. In particular, these mechanisms can prevent a client (but without knowing who that client is) from being affected by spoofing from other clients, even when the attackers are on the same communications path.
代替メカニズムは、この制限に対処し、公的にアクセス可能なサーバーが事前に不明なクライアントへの接続を確保できるようにするため、またはIPSECの残りの保護を利用可能にすることができるようにID検証の一方的な緩和を可能にするために開発中です[45] [46]。特に、これらのメカニズムは、攻撃者が同じ通信パスにいる場合でも、クライアントが他のクライアントからのスプーフィングによって影響を受けることをクライアント（しかし、そのクライアントが誰であるかを知らない）を防ぐことができます。
IPsec, although widely available both in commercial routers and commodity end-systems, is not often used except between parties that already have a preexisting relationship (employee/employer, between two ISPs, etc.). Servers to anonymous clients (e.g., customer/ business) or more open services (e.g., BGP, where routers may have large numbers of peers) are unmanageable, due to the breadth and flux of CAs. New endpoints cannot establish IPsec associations with such servers unless their own certificate is signed by a CA already trusted by the server. Different servers -- even within the same overall system (e.g., BGP) -- often cannot or will not trust overlapping subsets of CAs in general.
There are a number of application layer authentication mechanisms, often implicit within end-to-end encryption. Application layer security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) provides the ultimate protection of application data from all intermediaries, including network routers as well as exposure at other layers in the end-systems. This is the only way to ultimately protect the application data.
多くのアプリケーション層認証メカニズムがあり、多くの場合、エンドツーエンドの暗号化内で暗黙的です。アプリケーション層のセキュリティ（BGPストリーム内のTLS、SSH、またはMD5チェックサムなど）は、ネットワークルーターやエンドシステムの他の層での露出を含むすべての仲介者からのアプリケーションデータの究極の保護を提供します。これは、最終的にアプリケーションデータを保護する唯一の方法です。
Application authentication cannot protect either the network or transport protocols from spoofing attacks, however. Spoofed packets interfere with network processing or reset transport connections before the application checks the data. Authentication needs to winnow these packets and drop them before they interfere at these lower layers.
ただし、アプリケーション認証は、ネットワークまたは輸送プロトコルをスプーフィング攻撃から保護することはできません。スプーフィングされたパケットは、アプリケーションがデータをチェックする前に、ネットワーク処理またはリセットトランスポート接続を妨害します。認証は、これらのパケットがこれらの下層層に干渉する前に、これらのパケットを吹き飛ばしてドロップする必要があります。
An alternate application layer solution would involve resilience to reset connections. If the application can recover from such connection interruptions, then such attacks have less impact. Unfortunately, attackers still affect the application, e.g., in the cost of restarting connections, delays until connections are restarted, or increased connection establishment messages on the network. Some applications -- notably BGP -- even interpret TCP connection reliability as an indicator of route path stability, which is why attacks on BGP have such substantial consequences.
代替アプリケーションレイヤーソリューションには、接続をリセットするための回復力が含まれます。アプリケーションがそのような接続の中断から回復できる場合、そのような攻撃の影響は少なくなります。残念ながら、攻撃者は依然としてアプリケーションに影響を与えます。たとえば、接続を再起動するコスト、接続が再起動されるまで遅延、またはネットワーク上の接続確立メッセージの増加。一部のアプリケーション（特にBGP）は、TCP接続の信頼性をルートパスの安定性の指標として解釈することさえあります。そのため、BGPへの攻撃はそのような大きな結果をもたらします。
Link layer security operates separately on each hop of an Internet. Such security can be critical in protecting link resources, such as bandwidth and link management protocols. Protection at this layer cannot suffice for network or transport layers, because it cannot authenticate the endpoint source of a packet. Link authentication ensures only the source of the current link hop where it is examined.
リンクレイヤーセキュリティは、インターネットの各ホップで個別に動作します。このようなセキュリティは、帯域幅やリンク管理プロトコルなどのリンクリソースの保護に重要です。このレイヤーでの保護は、パケットのエンドポイントソースを認証できないため、ネットワークまたは輸送層には十分ではありません。リンク認証は、検査された現在のリンクホップのソースのみを保証します。
The issues raised in this section suggest that there are challenges with all solutions to transport protection from spoofing attacks. This raises the potential need for alternate security levels. While it is already widely recognized that security needs to occur simultaneously at many protocol layers, there also may be utility in supporting a variety of strengths at a single layer. For example, IPsec already supports a variety of algorithms (MD5, SHA1, etc., for authentication), but always assumes that:
このセクションで提起された問題は、スプーフィング攻撃からの輸送保護に対するすべての解決策に課題があることを示唆しています。これにより、代替セキュリティレベルの潜在的なニーズが高まります。多くのプロトコル層でセキュリティが同時に発生する必要があることはすでに広く認識されていますが、単一層でさまざまな強度をサポートする効用もあります。たとえば、IPSECはすでにさまざまなアルゴリズム（認証のためにMD5、SHA1など）をサポートしていますが、常に次のことを前提としています。
1. The entire body of the packet is secured.
1. パケットの全身が固定されています。
2. Security associations are established only where identity is authenticated by a known certificate authority or other pre-shared key.
2. セキュリティ協会は、既知の証明書当局またはその他の事前共有キーによってアイデンティティが認証される場合にのみ確立されます。
3. Both on-path and off-path third-party spoofing attacks must be defeated.
3. オンパスとオフパスのサードパーティのスプーフィング攻撃の両方を敗北させる必要があります。
These assumptions are prohibitive, especially in many cases of spoofing attacks. For spoofing, the primary issue is whether packets are coming from the same party the server can reach. Only the IP header is fundamentally in question, so securing the entire packet (1) is computational overkill. It is sufficient to authenticate the other party as "a party you have exchanged packets with", rather than establishing their trusted identity ("Bill" vs. "Bob") as in (2). Finally, many cookie systems use clear-text (unencrypted), fixed cookie values, providing reasonable (1 in 2^{cookie-size}) protection against off-path third-party spoof attacks, but not addressing on-path attacks at all. Such potential solutions are discussed in the Better Than Nothing Security (BTNS) documents [5][45][46]. Note also that NULL Encryption in IPsec applies a variant of this cookie, where the SPI is the cookie, and no further encryption is applied [17].
これらの仮定は、特にスプーフィング攻撃の多くの場合において法外なものです。スプーフィングの場合、主な問題は、サーバーが到達できるのと同じパーティからパケットが届いているかどうかです。IPヘッダーのみが根本的に問題になっているため、パケット全体（1）全体を保護することは計算の過剰です。（2）のように、信頼できるアイデンティティ（「ビル」対「ボブ」）を確立するのではなく、相手を「あなたがパケットを交換したパーティー」として認証するだけで十分です。最後に、多くのクッキーシステムは、クリアテキスト（暗号化されていない）、固定Cookie値を使用し、オフパスのサードパーティのスプーフィング攻撃に対する合理的な（2^{Cookie-Size}）保護を提供しますが、パス上の攻撃には対処しません。このような潜在的なソリューションは、より良いセキュリティ（BTNS）ドキュメント[5] [45] [46]で議論されています。また、IPSECのヌル暗号化は、SPIがCookieであり、それ以上の暗号化が適用されないこのCookieのバリアントを適用することに注意してください[17]。
This entire document focuses on increasing the security of transport protocols and their resistance to spoofing attacks. Security is addressed throughout.
このドキュメント全体は、輸送プロトコルのセキュリティの増加とスプーフィング攻撃に対する抵抗に焦点を当てています。セキュリティは全体を通して対処されています。
This document describes a number of techniques for defeating spoofing attacks. Those relying on clear-text cookies, either explicit or implicit (e.g., window sequence attenuation) do not protect from on-path spoofing attacks, since valid values can be learned from prior traffic. Those relying on true authentication algorithms are stronger, protecting even from on-path attacks, because the authentication hash in a single packet approaches the behavior of "one-time" cookies.
このドキュメントでは、スプーフィング攻撃を打ち負かすための多くの手法について説明しています。明示的または暗黙的（たとえば、ウィンドウシーケンス減衰）のいずれかのクリアテキストCookieに依存している人は、以前のトラフィックから有効な値を学ぶことができるため、パス上のスポーフ攻撃から保護しません。真の認証アルゴリズムに依存している人は、単一のパケットでの認証ハッシュが「1回限りの」Cookieの動作に近づくため、パス上の攻撃からも保護します。
The security of various levels of the protocol stack is addressed. Spoofing attacks are fundamentally identity masquerading, so we believe the most appropriate solutions defeat these at the network layer, where end-to-end identity lies. Some transport protocols subsume endpoint identity information from the network layer (e.g., TCP pseudo-headers), whereas others establish per-connection identity based on exchanged nonces (e.g., SCTP). It is reasonable, if not recommended, to address security at all layers of the protocol stack.
プロトコルスタックのさまざまなレベルのセキュリティに対処します。スプーフィング攻撃は根本的にアイデンティティの装備であるため、最も適切なソリューションは、エンドツーエンドのアイデンティティがあるネットワークレイヤーでこれらを打ち負かすと考えています。一部のトランスポートプロトコルは、ネットワークレイヤー（例：TCP疑似ヘッダー）からエンドポイントID情報を吸収しますが、他の輸送された非接続ごとのアイデンティティ（SCTPなど）に基づいて接続ごとのアイデンティティを確立します。プロトコルスタックのすべてのレイヤーでセキュリティに対処することは、推奨されていないとしても合理的です。
Note that Network Address Translators (NATs) and other middleboxes complicate the design and deployment of techniques to defeat spoofing attacks. Devices such as these, that modify IP and/or TCP headers in-transit, generate traffic equivalent to a spoofing attack, and thus should be inhibited by antispoofing mechanisms. Details of these middlebox-related problems are out of scope for this document, but issues thereof are addressed in RFCs and emerging documents that discuss the interactions between such devices and the Internet architecture, e.g., [21]. Fortunately, many of the most critical TCP-based connections -- in particular, those supporting routing protocols like BGP -- do not traverse such middleboxes, and are not affected by this limitation.
ネットワークアドレス翻訳者（NAT）およびその他のミドルボックスは、スプーフィング攻撃を打ち負かすためにテクニックの設計と展開を複雑にすることに注意してください。これらのようなデバイスは、輸送中のIPおよび/またはTCPヘッダーを変更し、スプーフィング攻撃に相当するトラフィックを生成するため、防毒メカニズムによって抑制される必要があります。これらのミドルボックス関連の問題の詳細はこのドキュメントの範囲外ですが、その問題は、そのようなデバイスとインターネットアーキテクチャ、例えば[21]の間の相互作用を議論するRFCおよび新たなドキュメントで対処されています。幸いなことに、最も重要なTCPベースの接続の多く、特にBGPのようなルーティングプロトコルをサポートするものは、そのような中間ボックスを通過せず、この制限の影響を受けません。
This document describes the details of the recent BGP spoofing attacks involving spurious RSTs, which could be used to shutdown TCP connections. It summarizes and discusses a variety of current and proposed solutions at various protocol layers.
このドキュメントでは、TCP接続をシャットダウンするために使用できるスプリアスRSTを含む最近のBGPスプーフィング攻撃の詳細について説明します。さまざまなプロトコル層でさまざまな電流および提案されたソリューションをまとめて説明します。
This document was inspired by discussions in the TCPM WG <http://www.ietf.org/html.charters/tcpm-charter.html> about the recent spoofed RST attacks on BGP routers, including R. Stewart's document (whose author list has since evolved) [36][42]. The analysis of the attack issues, alternate solutions, and the anonymous security proposed solutions were the result of discussions on that list as well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. R. Atkinson suggested the UDP variant of TCP/MD5, P. Goyette suggested using the ISN to seed TCP/MD5, and L. Wood suggested using the ISN to validate RSTs. Other improvements are due to the input of various members of the IETF's TCPM WG, notably detailed feedback from F. Gont, P. Savola, and A. Hoenes.
このドキュメントは、TCPM WG <http://www.ietf.org/html.charters/tcpm-charter.html>での議論に触発されました。それ以来進化しました）[36] [42]。攻撃の問題、代替ソリューション、および匿名のセキュリティ提案ソリューションの分析は、USC/ISIのT. Faber、A。Falk、G。Finn、およびY. Wangだけでなく、そのリストに関する議論の結果でした。R.アトキンソンは、TCP/MD5のUDPバリアント、P。ゴイエットがISNを使用してTCP/MD5をシードすることを提案し、L。ウッドはISNを使用してRSTを検証することを提案しました。その他の改善は、IETFのTCPM WGのさまざまなメンバーの入力によるものであり、F。Gont、P。Savola、およびA. Hoenesからの詳細なフィードバックです。
This document was prepared using 2-Word-v2.0.template.dot.
このドキュメントは、2ワード-V2.0.template.dotを使用して準備されました。
[1] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[1] Allman、M.、Paxson、V。、およびW. Stevens、「TCP混雑制御」、RFC 2581、1999年4月。
[2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[2] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[3] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
[3] Bellovin、S。およびA. Zinin、「TCP MD5署名オプション（RFC 2385）およびBGP-4仕様に関する標準の成熟度の差異」、RFC 4278、2006年1月。
[4] Bernstein, D., "SYN cookies", 1997, <http://cr.yp.to/syncookies.html>.
[4] Bernstein、D。、「Syn Cookies」、1997、<http://cr.yp.to/syncookies.html>。
[5] Better Than Nothing Security [BTNS] WG web pages, <http://www.postel.org/anonsec>.
[5] セキュリティ[BTNS] WG Webページ、<http://www.postel.org/anonsec>よりも優れています。
[6] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. Wheeler, "Authentication for TCP-based Routing and Management Protocols", Work in Progress, February 2007.
[6] Bonica、R.、Weis、B.、Viswanathan、S.、Lange、A。、およびO. Wheeler、「TCPベースのルーティングおよび管理プロトコルの認証」、2007年2月、Work in Progress。
[7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[7] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[8] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[8] Braden、R。、「TCPの時間待合暗殺の危険」、RFC 1337、1992年5月。
[9] CERT alert: "Technical Cyber Security Alert TA04-111A: Vulnerabilities in TCP", April 20, 2004, <http://www.us-cert.gov/cas/techalerts/TA04-111A.html>.
[9] CERT ALERT：「Technical Cyber Security Alert TA04-111A：TCPの脆弱性」、2004年4月20日、<http://www.us-cert.gov/cas/techalerts/ta04-111a.html>。
[10] Convery, S., and M. Franz, "BGP Vulnerability Testing: Separating Fact from FUD", 2003, <http://www.nanog.org/mtg-0306/pdf/franz.pdf>.
[10] Convery、S.、およびM. Franz、「BGP脆弱性テスト：FUDからの分離」、2003年、<http://www.nanog.org/mtg-0306/pdf/franz.pdf>。
[11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", Work in Progress, May 2007.
[11] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、2007年5月、進行中の作業。
[12] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999, pp. 1573- 1583, Mar. 1999.
[12] Faber、T.、J。Touch、およびW. Yue、「TCPにおけるタイムウェイト状態と忙しいサーバーへの影響」、Proc。Infocom 1999、pp。1573-1583、1999年3月。
[13] 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.
[13] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[14] Floyd、S。、「不適切なTCPリセットは有害と見なされる」、BCP 60、RFC 3360、2002年8月。
[15] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[15] Gill、V.、Heasley、J。、およびD. Meyer、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 3682、2004年2月。
[16] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", Work in Progress, June 2007.
[16] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、2007年6月の進行中。
[17] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[17] Glenn、R。およびS. Kent、「Null暗号化アルゴリズムとIPSECでの使用」、RFC 2410、1998年11月。
[18] Gont, F., "ICMP attacks against TCP", Work in Progress, May 2007.
[18] Gont、F。、「TCPに対するICMP攻撃」、2007年5月、進行中の作業。
[19] Gont, F., "TCP's Reaction to Soft Errors", Work in Progress, June 2007.
[19] Gont、F。、「ソフトエラーに対するTCPの反応」、2007年6月、進行中の作業。
[20] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[20] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[21] Holdrege、M。およびP. Srisuresh、「IPネットワークアドレス翻訳者とのプロトコルの合併症」、RFC 3027、2001年1月。
[22] Housley, R., Post to IETF Discussion mailing list regarding his IETF 64 Security Area presentation, ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24, 2005, <http://www1.ietf.org/ mail-archive/ietf/Current/maillist.html>.
[22] Housley、R.、IETFへの投稿への投稿IETF 64セキュリティエリアプレゼンテーション、ID = 0.0.0.20.2.2.20.2.20.2.20.20.2.20.20.20558@vigilsec.com、2005年11月24日、<http://www1.ietf.org/Mail-Archive/ietf/current/maillist.html>。
[23] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[23] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[24] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[24] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[25] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[26] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、RFC 4303、2005年12月。
[27] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[27] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[28] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[28] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram commestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[29] Larsen, M., and F. Gont, "Port Randomization", Work in Progress, February 2007.
[29] Larsen、M。、およびF. Gont、「ポートランダム化」、2007年2月、進行中の作業。
[30] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[30] Leech、M。、「TCP MD5署名オプションの主要な管理上の考慮事項」、RFC 3562、2003年7月。
[31] Moore, D., G. Voelker, and S. Savage, "Inferring Internet Denial-of-Service Activity", Proc. Usenix Security Symposium, Aug. 2001.
[31] Moore、D.、G。Voelker、およびS. Savage、「インターネット拒否アクティビティの推測」、Proc。Usenix Security Symposium、2001年8月。
[32] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991.
[32] O'Malley、S。およびL. Peterson、「TCP拡張は有害と見なされる」、RFC 1263、1991年10月。
[33] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[33] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[34] Poon, K., "Use of TCP timestamp option to defend against blind spoofing attack", Work in Progress, October 2004.
[34] POON、K。、「盲検スプーフィング攻撃から防御するためのTCPタイムスタンプオプションの使用」、2004年10月、進行中の作業。
[35] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[35] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[36] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, July 2007.
[36] Ramaiah、A.、Stewart、R。、およびM. Dalal、「Window In-Window攻撃に対するTCPの堅牢性の向上」、2007年7月の進行中。
[37] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[37] Rekhter、Y.、ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[38] Semke, J., J. Mahdavi, and M. Mathis, "Automatic TCP Buffer Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume 28, number 4, Oct. 1998.
[38] Semke、J.、J。Mahdavi、およびM. Mathis、「自動TCPバッファーチューニング」、ACM Sigcomm '98/ Computer Communication Review、Volume 28、Number 4、1998年10月。
[39] Shepard, T., "Reassign Port Number option for TCP", Work in Progress, July 2004.
[39] Shepard、T。、「TCPのポート番号オプションを再割り当て」、2004年7月、進行中の作業。
[40] Shirey, R., "Internet Security Glossary, Version 2", Work in Progress, November 2006.
[40] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、2006年11月、進行中の作業。
[41] 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.
[41] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV. Paxson、「ストリーム制御伝送プロトコル」、RFC 2960、2000年10月。
[42] TCPM: IETF TCPM Working Group and mailing list, <http://www.ietf.org/html.charters/tcpm-charter.html>.
[42] TCPM：IETF TCPMワーキンググループおよびメーリングリスト、<http://www.ietf.org/html.charters/tcpm-charter.html>。
[43] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[43] Touch、J。、「MD5パフォーマンスに関するレポート」、RFC 1810、1995年6月。
[44] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995, pp. 77-86, Mar. 1999.
[44] Touch、J。、「MD5のパフォーマンス分析」、Proc。Sigcomm 1995、pp。77-86、1999年3月。
[45] Touch, J., "ANONsec: Anonymous Security to Defend Against Spoofing Attacks", Work in Progress, May 2004.
[45] Touch、J。、「Anonsec：攻撃を防御するための匿名のセキュリティ」、2004年5月、進行中の作業。
[46] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Work in Progress, February 2007.
[46] Touch、J.、Black、D。、およびY. Wang、「Better than Nothing Security（BTNS）のための問題と適用声明」、2007年2月の作業。
[47] Touch, J. and A. Mankin, "The TCP Simple Authentication Option", Work in Progress, July 2007.
[47] Touch、J。およびA. Mankin、「TCP Simple認証オプション」、2007年7月、進行中の作業。
[48] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, <http://cansecwest.com/csw04archive.html>.
[48] Watson、P。、「窓の滑り：TCPリセット攻撃」、2004 Cansecwestでのプレゼンテーション、<http://cansecwest.com/csw04archive.html>。
[49] Wood, L., Post to TCPM mailing list regarding use of ISN in RSTs, ID=Pine.GSO.4.50.0404232249570.5889- 100000@argos.ee.surrey.ac.uk, Apr. 23, 2004, <http://www1.ietf.org/mail-archive/web/tcpm/current/ msg00213.html>.
[49] Wood、L.、RSTSでのISNの使用に関するTCPMメーリングリストへの投稿、id = pine.gso.4.50.0404232249570.5889-100000@argos.ee.ac.uk、2004年4月23日、<http：///////////////www1.ietf.org/mail-archive/web/tcpm/current/ msg00213.html>。
Author's Addresses
著者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676 Admiralty Way Marina Del Rey、CA 90292-6695 U.S.A.
Phone: +1 (310) 448-9151
Fax: +1 (310) 448-9300
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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ドキュメントの権利に関する手順に関する情報は、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.
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エディター機能の資金は現在、インターネット協会によって提供されています。