Network Working Group                                          J.  Touch
Request for Comments: 4953                                       USC/ISI
Category: Informational                                        July 2007
                 Defending TCP Against Spoofing Attacks

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




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送信元アドレス(スプーフィング)で送信された偽のリセット(のRST)へのTCP接続の増加脆弱性を示します。 TCPは常に間接的にRSTシーケンス番号が現在の受信ウィンドウの内側だけでなく、TCPエンドポイントとポート番号の難読化を経由していたことを確認することで保護されていた、そのようなRSTスプーフィング攻撃を受けやすくなっています。 BGPなどまたはウェブサーバとよく知られている大規模なキャッシュ間の予測可能なポートのペア、オーバーしばしば周知のエンドポイントのペアに対して、接続の経路の帯域幅遅延積の増加が十分にオフ受信ウィンドウスペースを増加していますパス第三者がブルートフォースができる実行可能な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
1. Introduction
1. はじめに

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.

インターネット基盤の分析は、最近オフパス攻撃者からRSTスプーフィングに基づいて攻撃を使用して、コア・ルータ間のBGP接続の脆弱性の新しいバージョンを示している[9] [10] [48]。攻撃自体はほぼ6年前に文書化された、新しいものではない[20]。そのような接続は、典型的には、TCPを使用して、TCP接続を終了偽造ソースアドレス(なりすまし)とオフパスサードパーティのリセット(RST)セグメント、影響を受けやすいことができます。 BGPルータは、BGPルート[37]他のルータが到達不能であると判断への接続を再開するので、フラッシング至るまで、攻撃の影響を増幅することができる様々な方法で終端するTCP接続に反応します。この種の攻撃は、よく知られたエンドポイント間の任意の長寿命の接続を含む、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.


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.

スプーフィングを無効にする一つの方法は、いずれかのトランスポート・レベルまたはネットワークレベルで、接続のセグメントを検証することです。 MD5拡張子を持つTCPは、トランスポート・レベルでこの認証を提供し、IPsecは、ネットワークレベル[20] [24] [27]に認証を提供します。どちらの場合も、その展開のオーバーヘッドが法外であってもよいし、例えば、それは(IPsecがインターネットキー交換プロトコルを使用するための(ピアの多数の適切な認証局で構成するために、Webサーバなどの公共サービスのために実行可能ではないかもしれません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のRST処理の変更[36]、修正を含むTCP / MD5およびIPsecに基づく既存の解決策、ならびに最近提案された解決策を含む様々なソリューションを比較します[45] TCPのタイムスタンプ処理[34]、およびIPsecとキーイングTCP / MD5へ変更します。スプーフィングされたTCPの内容に基づいて、ICMPパケットの関連なりすましの議論も説明されているが、この文書では、TCPセグメントのスプーフィングに焦点を当てています。

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]の開発のための理由だったされています。最近の攻撃のシナリオでは、最初の[10] 2003年のNANOG(北アメリカネットワークオペレータグループ)会議でConveryによって文書が、その分析は、シーケンス全体のスペース(2 ^ 32パケット)を成功させる攻撃の対象とすることが必要と仮定しました。ワトソンのより詳細な分析は、どこでも、現在のウィンドウ内の単一のパケットが攻撃[48]で成功することができることを発見しました。この文書では、攻撃に対する感受性が原因ウィンドウサイズと潜在的な攻撃の速度が直線的に増加を受けるの直線的な増加との間のカップリングには、帯域幅の2乗に比例している観測だけでなく、より最近の種々の提案を比較が追加されます、TCP、のIPsecの使用、及びそのような攻撃に抵抗するTCP / MD5の使用への変更を含みます。

2. Background

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上の潜在的な攻撃の最近の分析は、[48] [10] [9]オフパスサードパーティのスプーフィング攻撃にTCPの脆弱性の問題を改めて提起しました。このような攻撃の様々な既存の接続に影響を与えるかのサーバーをダウンロードするための試みでのRST、SYNの、さらにはACKを送信するなど、数年前から知られています。これらの攻撃は、多くの場合(例えば、IPを攻撃するためにアドレスを宛先ポート番号を示すために、そして時には初期シーケンス番号(ISN))最近のコンピュータやネットワーク帯域幅で有効にブルートフォース能力を持つが(例えば、すべてのスキャンする外部の知識を組み合わせて送信元ポートまたはウィンドウ全体空間)。全体として、このような攻撃は、ネットワーク(例えば、IPsecの)、輸送(例えば、SYNクッキー、TCP / MD5)、または他の層での認証の何らかの形態の使用によって相殺されます。 TCPは、既に現在の受信ウィンドウに対するセグメントシーケンス番号のチェックにおいて、そのような認証の弱形式を含みます。特定の長い接続の帯域幅遅延積の増加は十分お勧めできません、それへの依存を作るために、弱いこのタイプの認証を弱体化しています。

2.1. Review of TCP Windows
2.1. TCPのWindowsのレビュー

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 Receive window (RCV.WND): the latest advertised receive window size.


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.


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.


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

高帯域遅延積ネットワークは、ラウンドトリップタイムに輸送中に可能な限り多くのデータを収容するのに十分な大きさにCWNDを必要とします。そうでない場合は、彼らのパフォーマンスが低下します。その結果、ユーザと様々な自動プログラムは、帯域幅の少なくともサイズ*遅延(帯域幅遅延積)[23] [38]にRCV.WNDを増やすことが推奨されます。

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.


2.2. Recent BGP Attacks Using TCP RSTs
2.2. TCPののRSTを使用した最近のBGP攻撃

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


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:


o Both endpoint addresses are usually not well-known; although server addresses are advertised, clients are somewhat anonymous.


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 Valid sequence number space is not well-known.


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.


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接続の失敗を解釈しています。また、一度何らかの保護を提供すると考え、有効なシーケンス番号空間を大幅にウィンドウサイズを受信宣伝増加によって弱体化されています。

2.3. TCP RST Vulnerability
2.3. TCP RSTの脆弱性

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フラッドは、新しい接続を開くために、サーバの能力に影響を与える、ハーフオープン接続中のサーバリソースを消費する[4] [11]。 ACKスプーフィングは、接続がクロールに鈍化させ、ネットワークの輻輳およびセグメント損失を作成し、あまりにも速く、あまりにも多くのデータを送信するための接続を引き起こす可能性があります。 BGPの最近の攻撃では、のRSTは、接続が切断される原因となります。先に述べたように、いくつかのBGP実装は、ネットワーク障害[37]のように、TCP接続終了、またはそのような障害の一連の解釈します。これは、ルータがこのような攻撃の影響を増幅し、それらの継続的な交換を阻害することに加えて、既に交換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のRSTは、受信機は、すべての接続状態を低下させ、ソースがTIME_WAIT状態を維持するために必要とされないので、そのようなRSTは、潜在的に、以前の接続のセグメントがTIME_WAIT暗殺として知られる新たな接続のデータを、汚染することを可能にする、アドレス/ポートの対の早期の再利用を引き起こす可能性がある[8]。この場合には、暗殺は、正当なソースからの重複セグメントの結果として誤って発生し、TIME_WAITにおけるながらRST処理をブロックすることによって回避することができます。しかし、暗殺は故意のサーバーで開催された状態を軽減するために役立ちます。これは、の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]遷移接続に代わってのRSTを発します。これは事実上のRSTは、良性または有益な目的のために送信されたオンパスRST攻撃です。そのRFCに概説のRSTのような使用して、多くの危険があります。

2.4. What Changed - the Ever-Opening Advertised Receive Window
2.4. 何が変わった - エバー-オープニングアドバタイズには、ウィンドウを受信します

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.


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のために、正規のRSTは、送信機ウィンドウ内の次のシーケンス番号を使用するため、これが関連し、そして受信機は、着信のRSTが受信期待ウィンドウのシーケンス番号を持っていることをチェックします。このような処理は、(ただし、のRST用幾分議論の余地)重複セグメントを除去するために、前の接続の一部であったの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は、二つのウィンドウメカニズム、並べ替えおよび輻輳制御のための主要な機構(32ビットの空間を使用する)、およびこのウィンドウスケール二次機構[23] [35]を使用します。宣伝有効なウィンドウが、このスペースの約半分を超えないように、分数で受信、または〜2億円(2 * 10 ^ 9、すなわち、2E9または2米国億)。典型的な構成の下で、この空間、例えば、10,000-60,000(約5-100セグメント)の非常に小さな部分にオープンTCP接続の大半。広告を出して受信ウィンドウは通常、ソケットの受信バッファサイズと一致したためです。手動または自動の外部手段[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]など、パス帯域幅遅延積と一致するように設定されるべきである受け取ります。インターネットにおける多くの経路が(35,000バイト未満)上記のようにウィンドウを受け取る1下Mbpsでのエンドツーエンドの帯域幅、100ミリ秒下待ち時間を有し、15のホップの下にあり、かなり小さいアドバタイズもたらします。これらの条件下で、さらに初期シーケンス番号が適切であると仮定すると(擬似ランダムに)選択された、有効な推測シーケンス番号が受信ウィンドウアドバタイズ内に入るの57,000に1の確率を有するであろう。言い換えると、ブラインド(すなわち、オフパス)の攻撃者は、適切に間隔のシーケンス番号57000件のRSTを送信する必要があります成功した接続をリセットするために1往復時間以内に推測します。 1 Mbpsで、57,000(40バイト)のRSTは送信するだけで20秒かかりますが、これはIPアドレスおよび両方のポートの両方が知られていることを前提としています。送信元ポートの不在知識、オフパススプーファは91時間以上がかかる攻撃をもたらす、49152- 65535、または16,384の異なるポートの少なくとも全範囲を試みる必要があります。ほとんどの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メガバイトを超える帯域幅遅延製品の10 Gbpsおよび高い結果の高帯域幅パスの最近の使用 - TCPの全体的な最大値の約1/10は除く(すなわち、受信ソケットバッファを可能な限り増加していると仮定して)受信ウィンドウサイズを宣伝しましたスケール、(セクション2で説明したように)受信機が十分なバッファリングを割り当てると仮定。 10倍遅く(1 Gbps)のあるネットワークの下で、アドバタイズアクティブウィンドウが全体ウィンドウサイズの1/100を覆う受け取ります。これらの速度では、それが正しく、有効なシーケンス番号を推測し、接続を殺すために、唯一の10から100パケット未満、または32マイクロ秒かかります。 (更には100ミリ秒BGPケースの大きさであるが)のRSTの種々の量への暴露を対応のテーブルは、より従来の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


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.

2. Traffic losses are negligible (insufficient to affect the congestion window over the duration of most of the connection).


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.


4. The attack bandwidth is similar to the end-to-end path bandwidth.

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.図1は、大きな受信宣伝窓に基づく攻撃が成功するまでの時間をまとめた章で説明しましたが、現在の多くの商用ルータは、大きなデバイスの場合は128 KBの制限、32媒体のためのKB、およびなどほとんどありませんささやかなもののために4キロバイトとして。図2は、100ミリ秒の待ち時間のために示された時間でのBGPセッションに対する攻撃を達成するために必要な時間と帯域幅を示す図です。でも短距離ネットワーク遅延(10ミリ秒)のために、これらのセッションはまだ短い時間スケール(数分から数時間)かけて攻撃することができます。

          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


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


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.


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.


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.


3. Proposed Solutions and Mitigations

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.


3.1. Transport Layer Solutions
3.1. トランスポート層ソリューション

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、などの他のトランスポートプロトコルは、スプーフィングメカニズムが限られています。

3.1.1. TCP MD5 Authentication
3.1.1. TCP MD5認証

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

(それは、任意のTCP接続のために使用することができるが)TCP支持MD5認証の拡張は、具体的にはBGP接続を認証するために1998年に開発された[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].

昨今の衝突ベースの攻撃[22]にMD5を使用することについての懸念もあります。同様の問題は、SHA-1のために存在し、及びIETFは、現在、これらの攻撃は、TCP / MD5およびIPsecのスイートの両方において、これらのハッシュを使用するための推奨に影響を与える方法を評価しています。この議論の目的のために、いずれかのプロトコル・スイートで使用される特定のアルゴリズムは、フォーカスされないが、TCP / MD5は、より一般的なTCPセキュリティオプションに進化することを可能にする進行中の作業がある[6] [47]。

3.1.2. TCP RST Window Attenuation
3.1.2. TCP RSTウィンドウの減衰

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]と一致するようにRSTを受けました。これは事実上、単一の番号へのRSTのための受信ウィンドウを制限し、偽のRSTへのTCPの抵抗性を復元します。その結果、攻撃者はシーケンス番号推測力がブルートする2 ^ 32の異なるパケットを送信する必要がある(最悪の場合、平均値は半分となるであろう)。これは、TCPの脆弱性は、受信ウィンドウ(RCV.WND)の大きさとは独立して攻撃することができます。拡張は、更に、長さゼロのACKを送信することにより、誤っ番目のRSTに反応するようにRSTの受信機を変更します。 RSTのソースが正当である場合には、ACKを受信すると、クローズドソースは、おそらく正しく意図した受信者のリセット、ACKに一致するシーケンス番号を持つRSTを放出するであろう。この変更は、その複雑さを追加し、従って潜在的に(完全にTCP制御処理に直交する、MD5署名を追加することとは対照的に)、その正当性に影響を与え、TCPの制御処理を変更します。 RSTは、(前述したように)TIME-WAITを洗い流すため、例えば、エンドポイントの同一の対の間の異なる接続の間のRST合併症があってもよいです。 、いくつかの状況下で、RSTは、一般に認められた実際の違反で、応答(ACK)を引き起こす、そうでない場合穏やか推薦ようさらに、この提案は、TCPを変更する - これはタイムアウトが十分できるように、省略することもできます。この提案の利点は、インクリメンタルに展開することができ、それがデプロイされているエンドポイントに利益を得たということです。この提案への他の利点は、ここで説明するウィンドウの減衰が受信ウィンドウのサイズとは無関係に偽装された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の窓を減衰させるために別の値を使用しています。これは、初期シーケンス番号ではなく、次の予想されるシーケンス番号、すなわち、接続の確立にネゴシエートされた値[42] [49]を運ぶためのRSTを必要とします。この提案は、明示的にネゴシエートされた値を使用する利点がありますが、現在有効な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.

この提案の別の変形は、32ビットから64ビットに配列空間を増大させる、すなわち、TCPのウィンドウスペースを増大させるよりもむしろのRSTの有効な範囲を減少させることを含みます。これは、同等の効果を有している - 全体のシーケンス番号空間に任意のセグメントの有効なシーケンス番号の割合が大幅に低減されます。現在のスキームと同様に、初期シーケンス番号を使用して、弱い認証を確立するために、より大きな空間の使用、(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.


3.1.3. TCP Timestamp Authentication
3.1.3. TCPタイムスタンプ認証

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.


3.1.4. Other TCP Cookies
3.1.4. その他の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].

上記の技術の全ては、クッキーの変異体、その値がパケットを検証するために使用されているそれ以外の場合は無意味なデータです。 MD5チェックサムの場合は、クッキーは、共有秘密に基づいて計算されます。署名が推測、および攻撃の1 ^ 2(署名長)確率を提示することができることに留意されたいです。主な違いは、パケットデータに依存しているので、繰り返さないため、MD5の署名は、効果的にパススヌーピングに基づいて、一回限りのクッキーではなく、予測可能であるということです。ウィンドウ減衰シーケンス番号は、既存の接続の現在のパケットのシーケンス番号をスヌーピングすることによって推測することができ、タイムスタンプは、別個の良性の接続によって、またはそれらが概ね現地時間と相関仮定のいずれかによって、さらに少ない直接推測することができます。クッキーのこれらの変異体は、再び認証の(かなり弱く、除くMD5)フォームに基づいて、オフパスサードパーティのスプーフィング攻撃に対する脆弱性にパッチを適用、TCP SYNクッキーと精神が似ています。クッキーの別の形態は、ランダム化されたが、網羅的攻撃することができる保護の16ビットのみ(65,000組み合わせ)を提供することができるソースポート自体です。これは、同様に、宛先ポートのランダム化と組み合わせることができ、それは、と等価(およびなどの大規模な展開の場合と不可能)である個別の調整メカニズム(両当事者が使用するポートを知っている)、共有秘密[の交換を必要とします39]。

3.1.5. Other TCP Considerations
3.1.5. 他のTCPの考慮事項

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

RSTスプーフィングの可能性分析は、上記アドバタイズ受信ウィンドウは、エンドツーエンドパスの帯域幅遅延積によって示唆最大限に開放されていると仮定し、そしてウィンドウが全体のかなりの部分に開口されていることシーケンス番号空間。先に述べたように、最も一般的なケースのために、接続が短すぎるか、有用であるために、このような大きな窓には低すぎる帯域幅を超えています。 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.


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データはインターネットルータ間で交換されている最も最近のケースでは、データはバースト性で、集約トラフィックが(でも長寿命であれば、配列スペースのかなりの部分をカバーする可能性は低い、すなわち)小さいかもしれないので、小さな広告を出して、いくつかのケースでは、十分に当面の問題に対処することができる(小型レシーバ・バッファ経由)窓を受けます。これは、ルーティングテーブルが2つのルータ間、いくつかの他の信号、または時間を介して、例えば大バースト交換(時のみ開放される受信ウィンドウをアドバタイズ、または多分ことが小さいバッファに起因して減少した帯域幅で十分迅速に交換することができることを前提としていどちらかが非標準のだろうが)、信号をベース。

3.1.6. Other Transport Protocol Solutions
3.1.6. 他のトランスポートプロトコル・ソリューション

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の両方が接続確立のためのクッキーが含まれており、[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は、このような攻撃を倒すために、それ以降のRSTがブロックされている場合があります。これは、エンドポイントピア間で搬送状態をクリーンアップを妨げる可能性がある、その接続に正当なのRSTを遮断するの副作用を持っているでしょう。増加モニタリング負荷に結合され、この副作用は、一般的な場合に望ましくないような溶液をレンダリングするかもしれないが、それらは有用ルータのBGPのために、例えば、特別な場合に適用されるかもしれません。

3.2. Network Layer (IP) Solutions
3.2. ネットワーク層(IP)ソリューション

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.

アドレスフィルタリングおよびIPsec:スプーフィングへのネットワーク層ソリューションの二つの主要なバリエーションがあります。アドレスフィルタリングは攻撃の上流に送信されたパケットをフィルタリングするために他の当事者に依存している間接的なシステムであり、必ずしもパケット送信元の参加を必要としません。 IPsecは現在、共有鍵または共有認証局のいずれかの既存の共有知識を必要とする彼らの接続、上の攻撃を回避したいというエンドポイント間の協力が必要。

3.2.1. Address Filtering
3.2.1. アドレスフィルタリング

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


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.

アドレスフィルタリングのより最近の変形は接続[15]の他方の端部によって設定されたTTLに依存する、IP TTL(生存時間)フィールドをチェックします。この手法は、BGPのためのフィルタリングを提供するために使用されています。これは、接続元のTTLが255に設定されていると仮定します。受信側でのパケットは、TTL = 255がチェックされ、他は廃棄されます。これは、受信機(すなわち、BGPルータ)の上流に1つのホップへのトラフィックを制限しますが、それらのホップはそれらのノード(例えば、BGPルータのピア)、またはそれらのノードがトンネルを経由して受け入れるすべてのトラフィックで他のユーザプログラムを含めることができます - トンネルが必要ですので、 ([16]また、[15]のセクション5.1を参照)(BITW)特に「ワイヤでバンプ」のため、TTLをデクリメントまたはBITW相当シナリオ[33]ありません。 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).


3.2.2. IPsec
3.2.2. IPsecの

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はのRSTに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はしばしば面倒であり、ごく最近、多くのエンドシステムのオペレーティングシステムではサポートされています。さらに重要なことは、事前共有鍵に依存して、(例えば、IKEを介して)X.509証明書、または信頼できるサードパーティ(例えば、ケルベロス)鍵インフラストラクチャを確立し、交換鍵情報に署名しました。そのクライアントのIPsecをサポートしていないか、または以前に知られている認証局(CA)に登録されていない可能性があり、よく知られたサーバーへのトラフィックを保護するために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接続のリセット、パスMTUの攻撃など、TCP上のさまざまな攻撃を起動するために使用することができ、また、などの非TCPの死のピング」と「スマーフ攻撃」を持つホストを攻撃するために使用することができます[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.


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セグメントがICMPメッセージに含まれている場合)は、例えば、TCPチェックサムが検証されなければなりません。 TCP MD5オプションが存在する場合は同様に、その署名はおそらく、メッセージの内容を検討する前に検証する必要があります。そのような検証は、パケットは、パケットがソースにより送信されたものであった(IPSecまたはTCP / MD5が認証)は、ICMP生成(チェックサム)の前に破損していないことを確認し、またはすることができ、パケットが過剰のために、ネットワーク内ではなかったこと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].

以下の検証で - - も、いくつかの偽装されたTCPセグメントよりも、いくつかのメッセージがより簡単に接続をリセットすることができますので、ICMPは、特定の課題を提示しています。もう一つの提案の代替は、接続が確立された後のICMPにTCPの反応を変更することです。それは、接続の確立中に影響を受けやすいTCPのままにして、特定の有効なネットワーク・イベント[19]へのTCPの反応を変更することがあります。いくつかのトンネリング構成で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メッセージを必要とすることは、不十分な保護かもしれません。このような既存のIPsecアソシエーションを有する既知のドメイン内の接続またはルータのエンドポイントとして知られている信頼できるエンドポイントから発信するときICMPパケットが認証されることができます。残念ながら、彼らはまた、ネットワーク内の他の場所で発生することができます。加えて、いくつかのネットワークフィルタは、すべてのICMPパケットを検証は、それらがネットワークのどこからでも注入することができ、したがって容易かつローカルアドレスをフィルタリングすることができない、特にため、可能でないかもしれないので[27]。その結果、彼らはさらに、本書の問題やセキュリティ上の考慮事項で個別に対処されていません。

5. Issues

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.


5.1. Transport Layer (e.g., TCP)
5.1. トランスポート層(例えば、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.


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)を交渉して、レガシープロトコルは安全に強化するために難しいことで知られています。いないすべての認証ソリューションは、いずれか、同じように作成、およびトランスポートのさまざまなソリューションに頼ることは誤って指定または実装ソリューションの増加の潜在的にエンドシステムを公開しています。トランスポート認証は、多くの場合、[36] [4]、例えば、特定の攻撃に応答して、SYNクッキーとRSTウィンドウ減衰を区分開発されています。

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

トランスポート層のソリューションは、プロトコルごとの、しかし多くの場合、接続ごとではないだけです。これは、利点と欠点の両方を持っています。層ソリューションを輸送する一つの利点は、より低い層は、実装のバグに起因する、例えば、失敗したときに、トランスポートプロトコルを保護することができるということです。 TCPはすでにのRSTがインウィンドウであることを確認し、例えば、これらの場合に保護するために、パケットの検証のさまざまなメカニズムを含んでいます。より厳密なチェックが[(TCPsecureを介して)にウィンドウ終わるmisaddressedのRSTから保護するために、またはmisaddressedパケット(TCP / MD5)から起因のRST、SYNの、又はデータ噴射に接続中断から保護するために、例えば、提供される保護を増大させることができます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.


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.

欠点としては、各トランスポート接続が交渉し、個別に認証状態を維持する必要があります。ネットワーク層溶液中に場合のように、両方の - 他のオーバーヘッドは、異なるトランスポート・プロトコル、例えば、設計および実装の複雑にわたって償却されていないのに対し、いくつかのオーバーヘッドは、例えば、複数の接続を介してパケット交換におけるオーバーヘッドを償却されません。認証が必要とされるよりも、パケット処理の後半で行われるため、追加のエンドポイントリソースが無駄に消費されてもよい、例えば、分離に等パケット、インデクシング接続識別子、およびスプーフィングされたパケットをバッファリングし続けるが、受信した、唯一のトランスポート層で、後に滴下します。

5.2. Network Layer (IP)
5.2. ネットワーク層(IP)

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.


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

ESPのみIPデータ(例えば、トランスポート・ヘッダとペイロード)を認証する一方AHは、IPヘッダとIPデータの両方を認証します。 ESPは、より効率的であり、セキュリティパラメータインデックス(SPI)はとにかくIPヘッダを検証するために十分な情報を含んでいるのでAHは、[27]段階的に廃止されています。これら二つのモードは、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.


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の残りの保護を使用可能にすることができるように、公的にアクセス可能なサーバは、事前に知られている、または身元確認の一方的な緩和を可能にしていないクライアントへの接続を確保できるようにするために開発が進められている[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.

IPsecは、商用ルータやコモディティエンドシステムの両方で広く利用可能ものの、多くの場合、すでに(2つのISP間の従業員/雇用者、など)の既存の関係を持っている当事者間以外には使用されません。匿名クライアントへのサーバ(例えば、顧客/ビジネス)以上のオープンサービスが(例えば、ルータはピアの数が多いことBGPは、)によるCAの広さと束に、手に負えないです。自分の証明書がすでにサーバが信頼するCAによって署名されていない限り、新しいエンドポイントは、このようなサーバとのIPsecアソシエーションを確立することはできません。異なるサーバ - にも同じシステム全体(例えば、BGP)内は - 多くの場合、一般的にはCAの重複部分集合を信用しないであろうことはできませんか。

5.3. Application Layer
5.3. アプリケーション層

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.


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は - でも、BGPへの攻撃は、実質的な影響を持っている理由であるルート・パスの安定性の指標として、TCPの接続信頼性を解釈します。

5.4. Link Layer
5.4. リンク層

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.


5.5. Issues Discussion
5.5. 問題の議論

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:


1. The entire body of the packet is secured.

2. Security associations are established only where identity is authenticated by a known certificate authority or other pre-shared key.


3. Both on-path and off-path third-party spoofing attacks must be defeated.


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)のように彼らの信頼できるアイデンティティ(「ボブ」対「ビル」)を確立するよりも、「あなたが持つパケットを交換してきた政党」として、相手を認証するのに十分です。最後に、多くのクッキーシステムは、クリアテキスト(暗号化されていない)、固定されたクッキー値、オフパスサードパーティスプーフィング攻撃に対する合理(1 2 ^ {クッキーサイズ})保護を提供するが、全くにパス攻撃に対処しない使用します。このような潜在的な解決策は何もセキュリティ(BTNS)よりも優れたドキュメント[5] [45] [46]で議論されています。注意もIPsecの中にそのNULL暗号化は、SPIがクッキーである。このクッキーの変異体を適用し、それ以上の暗号化が適用されていない[17]。

6. Security Considerations

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.


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.


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ヘッダを変更するなりすまし攻撃へのトラフィック相当を生成し、ひいてはメカニズムをスプーフィングによって阻害されなければなりません。これらのミドル関連の問題の詳細については、この文書の範囲外であるが、問題はその、例えば、このようなデバイスやインターネットアーキテクチャ間の相互作用を議論するRFCと新興文書で対処されている[21]。幸いなことに、最も重要なTCPベースの接続の多くは - 特に、BGPなどのルーティングプロトコルをサポートするものは - 、このようなミドルボックスを横断していない、とこの制限の影響を受けません。

7. Conclusions

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.


8. Acknowledgments

This document was inspired by discussions in the TCPM WG <> 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.

この文書は、(著者リストR.スチュワートのドキュメントを含むBGPルータに関する最近の偽装されたRST攻撃、およそTCPM WG <>での議論に触発されました以来、進化している)[36] [42]。攻撃の問題、代替ソリューション、および匿名のセキュリティソリューション提案の分析は、そのリスト上だけでなく、USC / ISIのT.フェーバー、A.フォーク、G.フィン、およびY.王との協議の結果でした。 R.アトキンソンはP. Goyetteは、TCP / MD5をシードするISNを使用して提案し、TCP / MD5のUDPバリアントを示唆し、そしてL.ウッドのRSTを検証するためにISNを使用して提案しました。他の改良は、IETFのTCPM WG、F. Gont、P. Savola、およびA. Hoenesから特に詳細なフィードバックの種々のメンバーの入力によるものです。

This document was prepared using


9. Informative References

[1] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.

[1]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。

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

[2]ベイカー、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.ジニン、 "TCP MD5署名オプション(RFC 2385)およびBGP-4仕様に関して標準成熟差異"、RFC 4278、2006年1月。

[4] Bernstein, D., "SYN cookies", 1997, <>.

[4]バーンスタイン、D.、 "SYNクッキー"、1997年、<>。

[5] Better Than Nothing Security [BTNS] WG web pages, <>.

[5]何もセキュリティ[BTNS] WGのWebページよりベター、<>。

[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.、ヴァイス、B.、Viswanathanの、S.、ランゲ、A.、およびO.ウィーラー、 "TCPベースのルーティングおよび管理プロトコルのための認証"、進歩、2007年2月ワーク。

[7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[7]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。

[8] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.

[8]ブレーデン、R.、 "TCPでTIME-WAITの暗殺の危険"、RFC 1337、1992月。

[9] CERT alert: "Technical Cyber Security Alert TA04-111A: Vulnerabilities in TCP", April 20, 2004, <>.

[9] CERTの警告: "技術的なサイバー・セキュリティ警報TA04-111A:TCPの脆弱性"、2004年4月20日、<>を。

[10] Convery, S., and M. Franz, "BGP Vulnerability Testing: Separating Fact from FUD", 2003, <>.

[10] Convery、S.、およびM.フランツ、 "BGPの脆弱性テスト:FUDから事実を分離"、2003年、<>。

[11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", Work in Progress, May 2007.

[11]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、進歩、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]フェーバー、T.、J.タッチ、およびW.越、 "TCPとその効果でTIME-WAIT状態ビジーサーバー上"、PROC。インフォコム1999頁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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング:IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。

[14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.

[14]フロイド、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]ギル、V.、Heasley、J.、およびD.マイヤー、 "一般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]ギル、V.、Heasley、J.、マイヤー、D.、Savola、P.、エド。、および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]グレン、R.とS.ケント、 "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]ホールドレッジ、M.とP. Srisuresh、 "IPネットワークアドレス変換とプロトコルの合併症"、RFC 3027、2001年1月。

[22] Housley, R., Post to IETF Discussion mailing list regarding his IETF 64 Security Area presentation,, Nov. 24, 2005, < mail-archive/ietf/Current/maillist.html>.

[22] Housley氏、彼のIETF 64警備区域プレゼンテーションに関するR.、IETFの議論メーリングリストへのポスト、、2005年11月24日、<のhttp://www1.ietf .ORG /メールアーカイブ/ IETF /電流/ maillist.html>。

[23] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[23]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。

[24] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[24]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ(IKEv2の)プロトコル"、RFC 4306、2005年12月。

[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[25]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。

[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[26]ケント、S.、 "IPカプセル化セキュリティペイロード(ESP)"、RFC 4303、2005年12月。

[27] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[27]ケント、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]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル(DCCP)"、RFC 4340、2006年3月。

[29] Larsen, M., and F. Gont, "Port Randomization", Work in Progress, February 2007.

[29]ラーセン、M.、およびF. Gont、 "ポートランダム化"、進歩、2007年2月での作業。

[30] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.

[30]リーチ、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]ムーア、D.、G. Voelker、及びS.サベージ、PROC。 USENIXセキュリティシンポジウム、2001年8月。

[32] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991.

[32]オマリー、S.とL.ピーターソン、 "有害と考えられTCP拡張"、RFC 1263、1991年10月。

[33] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.

[33]パーキンス、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.


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

[35]ポステル、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.、スチュワート、R.、およびM. Dalal、 "ブラインドインウィンドウ攻撃への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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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.マシス、 "自動TCPバッファ調整"、ACM SIGCOMM '98 /コンピュータコミュニケーションレビュー、ボリューム28、ナンバー4、1998年10月。

[39] Shepard, T., "Reassign Port Number option for TCP", Work in Progress, July 2004.

[39]・シェパード、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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。

[42] TCPM: IETF TCPM Working Group and mailing list, <>.

[42] TCPM:IETF TCPMワーキンググループとメーリングリスト、<>。

[43] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.

[43]タッチ、J.、 "MD5のパフォーマンスに関する報告書"、RFC 1810、1995年6月。

[44] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995, pp. 77-86, Mar. 1999.

[44]タッチ、J.、 "MD5の性能解析"、PROC。 SIGCOMM 1995、頁77-86、1999年3月。

[45] Touch, J., "ANONsec: Anonymous Security to Defend Against Spoofing Attacks", Work in Progress, May 2004.


[46] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Work in Progress, February 2007.

[46]タッチ、J.、ブラック、D.、およびY.王、 "問題とベター・ザンナッシングセキュリティ(BTNS)のための適用性に関する声明"、進歩、2007年2月での作業。

[47] Touch, J. and A. Mankin, "The TCP Simple Authentication Option", Work in Progress, July 2007.

[47]タッチ、J.およびA.マンキン、 "TCP簡易認証オプション"、進歩、2007年7月の作業。

[48] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, <>.

[48]ワトソン、P.、 "ウィンドウに滑り:TCPリセット攻撃"、2004たCanSecWestでのプレゼンテーション、<>。

[49] Wood, L., Post to TCPM mailing list regarding use of ISN in RSTs, ID=Pine.GSO.4.50.0404232249570.5889-, Apr. 23, 2004, < msg00213.html>.

[49]木材、L.、のRSTでISNの使用に関するポストTCPMにメーリングリスト、ID = Pine.GSO.4.50.0404232249570.5889-、2004年4月23日、<HTTP :// msg00213.html>。

Author's Addresses


Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.

ジョー・タッチUSC / ISI 4676アドミラルティWayマリナデルレイ、カリフォルニア州90292から6695 U.S.A.

Phone: +1 (310) 448-9151 Fax: +1 (310) 448-9300 EMail: URI:

電話:+1(310)448-9151ファックス:+1(310)448-9300 Eメール URI:

Full Copyright Statement


Copyright (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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。