Internet Engineering Task Force (IETF)                        A. Ramaiah
Request for Comments: 5961                                         Cisco
Category: Standards Track                                     R. Stewart
ISSN: 2070-1721                                                   Huawei
                                                                M. Dalal
                                                                   Cisco
                                                             August 2010
        
         Improving TCP's Robustness to Blind In-Window Attacks
        

Abstract

抽象

TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks.

TCPは、歴史的に、32と組み合わせて、4タプル(送信元および宛先IPアドレスと送信元ポートと宛先ポート)を推測することが困難であるという事実に依存することによって偽装されたオフパスパケットインジェクション攻撃から保護すると考えられていますビットシーケンス番号(複数可)。長期的な接続を使用して増加させるウィンドウサイズとアプリケーションの組み合わせ(例えば、H-323またはボーダーゲートウェイプロトコル(BGP)[RFC4271])スプーフィングされたパケットインジェクション攻撃のこれらの種類に対してより脆弱モダンTCPの実装を残しています。

Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack.

これらの長期的なTCPアプリケーションの多くが推測される(4タプルは、RFC 793で述べたソケットペアと同じである)4タプルのために、それははるかに容易になり、予測可能なIPアドレスとポートを持っている傾向があります。正しく4タプルを推測したが、攻撃者は、RSTとTCPセグメントを注入することができるビットセット、SYN体系現在の受信ウィンドウにあるように偽装セグメントのシーケンス番号を推測することによって、TCP接続にセットまたはデータビットです。これは、接続が中断したり、データの破損を引き起こす可能性があります。このドキュメントでは、TCPは、攻撃の成功の可能性を減らすことができ、インバウンドのセグメントを処理する方法に小さな変更を指定します。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース(IETF)の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ(IESG)によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5961.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5961で取得することができます。

Copyright Notice

著作権表示

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(http://trustee.ietf.org/license-info)に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Applicability Statement ....................................3
      1.2. Basic Attack Methodology ...................................4
      1.3. Attack probabilities .......................................5
   2. Terminology .....................................................7
   3. Blind Reset Attack Using the RST Bit ............................7
      3.1. Description of the Attack ..................................7
      3.2. Mitigation .................................................7
   4. Blind Reset Attack Using the SYN Bit ............................9
      4.1. Description of the Attack ..................................9
      4.2. Mitigation .................................................9
   5. Blind Data Injection Attack ....................................10
      5.1. Description of the Attack .................................10
      5.2. Mitigation ................................................11
   6. Suggested Mitigation Strengths .................................12
   7. ACK Throttling .................................................12
   8. Backward Compatibility and Other Considerations ................13
   9. Middlebox Considerations .......................................14
      9.1. Middlebox That Resend RSTs ................................14
      9.2. Middleboxes That Advance Sequence Numbers .................15
      9.3. Middleboxes That Drop the Challenge ACK ...................15
   10. Security Considerations .......................................16
   11. Contributors ..................................................17
   12. Acknowledgments ...............................................17
   13. References ....................................................17
      13.1. Normative References .....................................17
      13.2. Informative References ...................................17
        
1. Introduction
1. はじめに

TCP [RFC0793] is widely deployed and the most common reliable end-to-end transport protocol used for data communication in today's Internet. Yet, when it was standardized over 20 years ago, the Internet was a different place, lacking many of the threats that are now common. The off-path TCP spoofing attacks, which are seen in the Internet today, fall into this category.

TCP [RFC0793]広く展開されており、今日のインターネットでのデータ通信に使用される最も一般的な信頼性の高いエンドツーエンドのトランスポートプロトコル。それは20年以上前に標準化されたときはまだ、インターネットは今や共通している脅威の多くを欠いている、別の場所でした。今日のインターネットで見られるオフパスTCPスプーフィング攻撃は、このカテゴリーに入ります。

In a TCP spoofing attack, an off-path attacker crafts TCP packets by forging the IP source and destination addresses as well as the source and destination ports (referred to as a 4-tuple value in this document). The targeted TCP endpoint will then associate such a packet with an existing TCP connection. It needs to be noted that, guessing this 4-tuple value is not always easy for an attacker. But there are some applications (e.g., BGP [RFC4271]) that have a tendency to use the same set(s) of ports on either endpoint, making the odds of correctly guessing the 4-tuple value much easier. When an attacker is successful in guessing the 4-tuple value, one of three types of injection attacks may be waged against a long-lived connection. RST - Where an attacker injects a RST segment hoping to cause the connection to be torn down. "RST segment" here refers to a TCP segment with the RST bit set. SYN - Where an attacker injects a SYN hoping to cause the receiver to believe the peer has restarted and therefore tear down the connection state. "SYN segment" here refers to a TCP segment with SYN bit set. DATA - Where an attacker tries to inject a DATA segment to corrupt the contents of the transmission. "DATA segment" here refers to any TCP segment containing data.

TCPスプーフィング攻撃では、IPソースアドレスと宛先アドレスならびにソースおよび宛先ポートを鍛造することによって、オフパス攻撃工芸TCPパケットが(この文書中の4-タプル値と呼びます)。対象とTCPエンドポイントは、既存のTCP接続で、このようなパケットを関連付けます。これは、この4タプル値を推測することは、常に攻撃者にとって容易ではないことに注意する必要があります。しかし、正しく4タプルの値を推測する確率がはるかに容易になり、いずれかのエンドポイント上の同じセットのポート(複数可)を使用する傾向があり、いくつかのアプリケーション(例えば、BGP [RFC4271])が存在します。攻撃者は4タプルの値を推測するに成功した場合、インジェクション攻撃の3つのタイプは、長寿命の接続に対して繰り広げてもよいです。 RST - 攻撃者は、接続を起こすことを期待してRSTセグメントを注入取り壊されます。 「RSTセグメントは、」ここにRSTビットが設定されたTCPセグメントを意味します。 SYN - 攻撃者が受信機は、ピアが再起動し、したがって、接続状態を切断していると信じさせることを望んでSYNを注入します。 「SYNセグメント」はここでSYNビットが設定されたTCPセグメントを指します。 DATA - 攻撃者が送信の破損コンテンツへのデータセグメントを注入しようとします。ここでは、「データセグメントは、」データを含む任意のTCPセグメントを意味します。

1.1. Applicability Statement
1.1. 適用性に関する声明

This document talks about some known in-window attacks and suitable defenses against these. The mitigations suggested in this document SHOULD be implemented in devices that regularly need to maintain TCP connections of the kind most vulnerable to the attacks described in this document. Examples of such TCP connections are the ones that tend to be long-lived and where the connection endpoints can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations MAY be implemented in other cases.

いくつか知られている中、窓の攻撃およびこれらに対して、適切な防御策についてこの文書で会談。この文書で提案緩和策は、定期的に、この文書で説明された攻撃に対して最も脆弱な種類のTCP接続を維持するために必要なデバイスに実装する必要があります。このようなTCP接続の例には、寿命の長い、どこ接続エンドポイントがTCP MD5 [RFC2385]のようないかなる補助スプーフィング防止保護メカニズムを展開することができない場合には、決定することが可能となる傾向があるものです。これらの緩和策は、他の例で実施することができます。

1.2. Basic Attack Methodology
1.2. 基本的な攻撃手法

Focusing upon the RST attack, we examine this attack in more detail to get an overview as to how it works and how this document addresses the issue. For this attack, the goal is for the attacker to cause one of the two endpoints of the connection to incorrectly tear down the connection state, effectively aborting the connection. One of the important things to note is that for the attack to succeed the RST needs to be in the valid receive window. It also needs to be emphasized that the receive window is independent of the current congestion window of the TCP connection. The attacker would try to forge many RST segments to try to cover the space of possible windows by putting out a packet in each potential window. To do this, the attacker needs to have or guess several pieces of information namely:

RST攻撃時に着目し、我々はそれが動作し、この文書は問題に対処する方法方法についての概要を取得するために、より詳細にこの攻撃を調べます。この攻撃では、目標は、接続の2つのエンドポイントの1つが誤って効果的に接続を中断、接続状態を切断させるための攻撃のためです。注意すべき重要なことの一つは、攻撃が成功するためにRSTが有効な受信ウィンドウにあることが必要であるということです。また、受信ウィンドウがTCP接続の現在の輻輳ウィンドウとは無関係であることを強調する必要があります。攻撃者は、各電位窓にパケットを出すことによって可能に窓のスペースをカバーしようとする多くのRSTセグメントを偽造しようとするだろう。これを行うには、攻撃者はすなわち、いくつかの情報を持っているかを推測する必要があります。

1) The 4-tuple value containing the IP address and TCP port number of both ends of the connection. For one side (usually the server), guessing the port number is a trivial exercise. The client side may or may not be easy for an attacker to guess depending on a number of factors, most notably the operating system and application involved.

1)接続の両端のIPアドレスとTCPポート番号を含む4タプル値。片側(通常はサーバー)の場合は、ポート番号を推測することは簡単な運動です。攻撃者は多くの要因、関与する最も顕著なオペレーティングシステムやアプリケーションに応じて推測するために、クライアント側は、または簡単であってもなくてもよいです。

2) A sequence number that will be used in the RST. This sequence number will be a starting point for a series of guesses to attempt to present a RST segment to a connection endpoint that would be acceptable to it. Any random value may be used to guess the starting sequence number.

2)RSTに使用されるシーケンス番号。このシーケンス番号は、それに対して許容されるであろう接続エンドポイントにRSTセグメントを提示しようとする推測の一連のための出発点となります。任意のランダムな値は開始シーケンス番号を推測するために使用することができます。

3) The window size that the two endpoints are using. This value does NOT have to be the exact window size since a smaller value used in lieu of the correct one will just cause the attacker to generate more segments before succeeding in his mischief. Most modern operating systems have a default window size that usually is applied to most connections. Some applications however may change the window size to better suit the needs of the application. So often times the attacker, with a fair degree of certainty (knowing the application that is under attack), can come up with a very close approximation as to the actual window size in use on the connection.

3)2つのエンドポイントが使用されるウィンドウ・サイズ。この値が正しいの代わりに使用する値が小さいほどちょうど彼のいたずらに成功する前に複数のセグメントを生成するために、攻撃者が発生しますので、正確なウィンドウサイズである必要はありません。最近のほとんどのオペレーティングシステムは通常、ほとんどの接続に適用されるデフォルトのウィンドウサイズを持っています。一部のアプリケーションでは、しかし、より良いアプリケーションのニーズに合うようにウィンドウのサイズを変更することがあります。だから、多くの場合、確実性の公正度回攻撃者は、(攻撃されているアプリケーションを知っている)、接続で使用中の実際のウィンドウサイズにとして非常に近い近似値を思い付くことができます。

After assembling the above set of information, the attacker begins sending spoofed TCP segments with the RST bit set and a guessed TCP sequence number. Each time a new RST segment is sent, the sequence number guess is incremented by the window size. The feasibility of this methodology (without mitigations) was first shown in [SITW]. This is because [RFC0793] specifies that any RST within the current window is acceptable. Also, [RFC4953] talks about the probability of a successful attack with varying window sizes and bandwidth.

情報の上記集合を組み立てた後、攻撃者はRSTとスプーフィングされたTCPセグメントの送信を開始設定ビットと推測TCPシーケンス番号。新しいRSTセグメントが送信されるたびに、シーケンス番号の推測は、ウィンドウサイズによって増加されます。 (緩和策なし)この方法の実現可能性は、最初の[SITW]に示しました。 [RFC0793]は現在のウィンドウ内の任意のRSTが許容可能であることを指定するためです。また、[RFC4953]は、様々なウィンドウサイズと帯域幅を持つ攻撃が成功する確率について語っています。

A slight enhancement to TCP's segment processing rules can be made, which makes such an attack much more difficult to accomplish. If the receiver examines the incoming RST segment and validates that the sequence number exactly matches the sequence number that is next expected, then such an attack becomes much more difficult than outlined in [SITW] (i.e., the attacker would have to generate 1/2 the entire sequence space, on average). This document will discuss the exact details of what needs to be changed within TCP's segment processing rules to mitigate all three types of attacks (RST, SYN, and DATA).

TCPのセグメント処理規則へのわずかな改善が達成するために、このような攻撃ははるかに困難にしている、行うことができます。受信機は、受信RSTセグメントを検査し、シーケンス番号が正確に次の期待されるシーケンス番号と一致することを検証した場合、そのような攻撃がはるかに困難[SITW]に概説よりなる(すなわち、攻撃者が1/2を生成しなければなりません平均的に全体のシーケンススペース、)。この文書では、攻撃(RST、SYN、およびDATA)の3種類すべてを軽減するためにTCPのセグメント処理ルール内で変更する必要があるものの正確な詳細を説明します。

1.3. Attack probabilities
1.3. 攻撃確率

Every application has control of a number of factors that drastically affect the probability of a successful spoofing attack. These factors include such things as:

すべてのアプリケーションは大幅に成功したスプーフィング攻撃の確率に影響を与える要素の数を制御しています。これらの要因は、のようなものが含まれています。

Window Size - Normally settable by the application but often times defaulting to 32,768 or 65,535 depending upon the operating system (see Figure 6 of [Medina05]).

ウィンドウサイズ - 通常アプリケーションによって設定可能しかししばしば、オペレーティングシステムに応じて32,768または65,535をデフォルト([Medina05]の図6を参照)。

Server Port number - This value is normally a fixed value so that a client will know where to connect to the peer. Thus, this value normally provides no additional protection.

サーバーのポート番号 - クライアントはどこピアへの接続方法を知っているように、この値は、通常は固定値です。したがって、この値は、通常、追加の保護を提供しません。

Client Port number - This value may be a random ephemeral value, if so, this makes a spoofing attack more difficult. There are some clients, however, that for whatever reason either pick a fixed client port or have a very guessable one (due to the range of ephemeral ports available with their operating system or other application considerations) for such applications a spoofing attack becomes less difficult.

クライアントポート番号 - そう、これはスプーフィング攻撃がより困難にしている場合、この値は、ランダム短命値であってもよいです。一部のクライアントは、スプーフィング攻撃がそれほど難しくなり、何らかの理由で、このような用途のために(それらのオペレーティングシステムや他のアプリケーションの考慮事項で利用可能なエフェメラルポートの範囲に)固定クライアントポートを選ぶか、非常に推測可能なものを持っているのどちらかということがありますが、 。

For the purposes of the rest of this discussion we will assume that the attacker knows the 4-tuple values. This assumption will help us focus on the effects of the window size versus the number of TCP packets an attacker must generate. This assumption will rarely be true in the real Internet since at least the client port number will provide us with some amount of randomness (depending on the operating system).

この議論の残りの目的のために我々は、攻撃者は4タプル値を知っていると仮定します。この仮定は、攻撃者が生成しなければならないTCPパケットの数に対するウィンドウサイズの影響に焦点を当てて私たちを助けます。少なくともクライアントのポート番号は、(オペレーティングシステムによって異なります)ランダムある程度の量を提供してくれるので、この仮定はめったに実際のインターネットに真になることはありません。

To successfully inject a spoofed packet (RST, SYN, or DATA), in the past, the entire sequence space (i.e., 2^32) was often considered available to make such an attack unlikely. [SITW] demonstrated that this assumption was incorrect and that instead of (1/2 * 2^32) packets (assuming a random distribution), (1/2 * (2^32/window)) packets are required. In other words, the mean number of tries needed to inject a RST segment is (2^31/window) rather than the 2^31 assumed before.

正常偽装パケット(RST、SYN、またはDATA)を注入するために、過去に、全配列空間(すなわち、2 ^ 32)は、多くの場合、そのような攻撃はそうするために利用できると考えられました。 [SITW](1/2 *(2 ^ 32 /ウィンドウ))パケットが必要であり、この仮定が間違っていたことを実証し、代わりに(1/2 * 2 ^ 32)パケットの(ランダムな分布を仮定)こと。換言すれば、RSTセグメントを注入するために必要な試行の平均数は、かなり前に想定2 ^ 31よりも(2 ^ 31 /ウィンドウ)です。

Substituting numbers into this formula, we see that for a window size of 32,768, an average of 65,536 packets would need to be transmitted in order to "spoof" a TCP segment that would be acceptable to a TCP receiver. A window size of 65,535 reduces this even further to 32,768 packets. At today's access bandwidths, an attack of that size is feasible.

この式に数値を代入すると、我々は、32,768のウィンドウサイズのために、65,536パケットの平均値が「なりすまし」TCP受信機に許容されるであろうTCPセグメントに順に送信する必要があることがわかります。 65,535のウィンドウサイズが32,768パケットにも、このことをさらに低減します。今日のアクセス帯域幅で、その大きさの攻撃が可能です。

With rises in bandwidth to both the home and office, it can only be expected that the values for default window sizes will continue to rise in order to better take advantage of the newly available bandwidth. It also needs to be noted that this attack can be performed in a distributed fashion in order potentially gain access to more bandwidth.

家庭やオフィスの両方に帯域幅の上昇と、それだけで、デフォルトのウィンドウサイズの値が良く、新たに利用可能な帯域幅を利用するためには上昇し続けることを期待することができます。また、潜在的に、より多くの帯域幅へのアクセスを得るために、この攻撃は分散方式で実行することができることに注意する必要があります。

As we can see from the above discussion this weakness lowers the bar quite considerably for likely attacks. But there is one additional dependency that is the duration of the TCP connection. A TCP connection that lasts only a few brief packets, as often is the case for web traffic, would not be subject to such an attack since the connection may not be established long enough for an attacker to generate enough traffic. However, there is a set of applications, such as BGP [RFC4271], that is judged to be potentially most affected by this vulnerability. BGP relies on a persistent TCP session between BGP peers. Resetting the connection can result in term-medium unavailability due to the need to rebuild routing tables and route flapping; see [NISCC] for further details.

我々は上記の議論からわかるように、この弱点はかなりかなりありそうな攻撃のためのバーを下げます。しかし、TCP接続の間で一つの追加の依存関係があります。接続は十分なトラフィックを生成するために、攻撃者のために十分な長さに確立されていない可能性があるため、多くの場合、Webトラフィックの場合のように、唯一のいくつかの簡単なパケットを持続するTCPコネクションは、このような攻撃の対象にはならないでしょう。しかし、潜在的に最もこの脆弱性の影響を受けていると判断されるBGPなどのアプリケーションのセット、[RFC4271]は、存在します。 BGPは、BGPピア間の永続的なTCPセッションに依存しています。接続をリセットすることは、羽ばたきルーティングテーブルおよびルートを再構築する必要性という用語は、媒体使用不能をもたらすことができます。詳細は[NISCC]を参照してください。

For applications that can use the TCP MD5 option [RFC2385], such as BGP, that option makes the attacks described in this specification effectively impossible. However, some applications or implementations may find that option expensive to implement.

BGPなどのTCP MD5オプション[RFC2385]を使用できるアプリケーションについては、そのオプションは、この明細書に記載された攻撃が効果的に不可能になります。ただし、一部のアプリケーションや実装が実装するために高価なそのオプションを見つけることができます。

There are alternative protections against the threats that this document addresses. For further details regarding the attacks and the existing techniques, please refer to [RFC4953]. It also needs to be emphasized that, as suggested in [TSVWG-PORT] and [RFC1948], port randomization and initial sequence number (ISN) randomization would help improve the robustness of the TCP connection against off-path attacks.

このドキュメントのアドレスその脅威に対する代替保護があります。攻撃や既存の技術に関する詳細については、[RFC4953]を参照してください。また、ポートのランダム化および初期シーケンス番号(ISN)ランダム化は、オフパス攻撃に対するTCP接続の堅牢性を向上させる助けとなる、[TSVWG-PORT]で提案されているように、ということと、[RFC1948]を強調する必要があります。

2. Terminology
2.用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. TCP terminology should be interpreted as described in [RFC0793].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。 [RFC0793]に記載されているようにTCP用語は解釈されるべきです。

3. Blind Reset Attack Using the RST Bit
RSTビットを使用して3.ブラインドリセットアタック
3.1. Description of the Attack
3.1. 攻撃の説明

As described in the introduction, it is possible for an attacker to generate a RST segment that would be acceptable to a TCP receiver by guessing in-window sequence numbers. In particular [RFC0793], page 37, states the following:

冒頭で説明したように、攻撃者は、インウィンドウシーケンス番号を推測することにより、TCP受信機に許容されるであろうRSTセグメントを生成することが可能です。特定[RFC0793]、ページ37において、次の状態:

In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.

SYN-SENTを除くすべての状態においては、全てのリセット(RST)セグメントは、それらのSEQフィールド[シーケンス番号]をチェックすることによって検証されます。そのシーケンス番号がウィンドウ内にある場合にはリセットが有効です。 ACKフィールドはSYNを認めた場合にSYN-SENT状態(RSTが初期SYNに応答して受信された)、RSTが許容可能です。

3.2. Mitigation
3.2. 緩和

[RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows:

[RFC0793]は、現在、次のように同期した状態で処理されるRSTビットを有するセグメントの取り扱いを必要とします。

1) If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND), silently drop the segment.

RSTビットが設定され、シーケンス番号が現在の受信ウィンドウ(SEG.SEQ <= RCV.NXT || SEG.SEQ> RCV.NXT + RCV.WND)外である場合は1)、サイレントセグメントをドロップ。

2) If the RST bit is set and the sequence number is acceptable, i.e., (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then reset the connection.

RSTビットが設定され、シーケンス番号が許容されている場合2)、すなわち、(RCV.NXT <= SEG.SEQ <RCV.NXT + RCV.WND)は、その後、接続をリセットします。

Instead, implementations SHOULD implement the following steps in place of those specified in [RFC0793] (as listed above).

(上記のように)の代わりに、実装は[RFC0793]で指定されたものに代えて、以下のステップを実装する必要があります。

1) If the RST bit is set and the sequence number is outside the current receive window, silently drop the segment.

RSTビットが設定され、シーケンス番号が現在の受信ウィンドウの外である場合は1)、サイレントセグメントをドロップ。

2) If the RST bit is set and the sequence number exactly matches the next expected sequence number (RCV.NXT), then TCP MUST reset the connection.

RSTビットが設定され、シーケンス番号が正確に次の予想されるシーケンス番号(RCV.NXT)と一致している場合2)、次いで、TCP接続をリセットする必要があります。

3) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the current receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST send an acknowledgment (challenge ACK):

RSTビットが設定され、シーケンス番号が正確に次の予想されるシーケンス値と一致しない場合3)、まだ現在の受信ウィンドウ(RCV.NXT <SEG.SEQ <RCV.NXT + RCV.WND)内で、TCPは、送信しなければなりません確認応答(ACK挑戦):

<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

<SEQ = SND.NXT> <ACK = RCV.NXT> <CTL = ACK>

After sending the challenge ACK, TCP MUST drop the unacceptable segment and stop processing the incoming packet further. Further segments destined to this connection will be processed as normal.

チャレンジACKを送信した後、TCPは、容認できないセグメントをドロップし、さらに着信パケットの処理を停止しなければなりません。この接続に宛てさらなるセグメントは通常通り処理されます。

The modified RST segment processing would thus become:

修飾されたRSTセグメント処理は、このようになります。

In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number exactly matches the next expected sequence number. If the RST arrives and its sequence number field does NOT match the next expected sequence number but is within the window, then the receiver should generate an ACK. In all other cases, where the SEQ-field does not match and is outside the window, the receiver MUST silently discard the segment.

SYN-SENTを除くすべての状態においては、全てのリセット(RST)セグメントは、それらのSEQフィールド[シーケンス番号]をチェックすることによって検証されます。そのシーケンス番号が正確に次に予想されるシーケンス番号と一致した場合にリセットが有効です。 RSTが到着し、そのシーケンス番号フィールドは、次に予想されるシーケンス番号と一致していませんが、ウィンドウ内にある場合、受信機はACKを生成する必要があります。 SEQフィールドが一致し、ウィンドウ外でない他のすべての場合において、受信機は静かセグメントを破棄しなければなりません。

In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. In all other cases the receiver MUST silently discard the segment.

ACKフィールドはSYNを認めた場合にSYN-SENT状態(RSTが初期SYNに応答して受信された)、RSTが許容可能です。他のすべての場合において、受信機は静かセグメントを破棄しなければなりません。

With the above slight change to the TCP state machine, it becomes much harder for an attacker to generate an acceptable reset segment.

TCP状態機械に上記わずかな変化と、それが許容されるリセットセグメントを生成するために、攻撃者にとって非常に困難となります。

In cases where the remote peer did generate a RST, but it fails to meet the above criteria (the RST sequence number was within the window but NOT the exact expected sequence number), when the challenge ACK is sent back, it will no longer have the transmission control block (TCB) related to this connection and hence as per [RFC0793], the remote peer will send a second RST back. The sequence number of the second RST is derived from the acknowledgment number of the incoming ACK. This second RST, if it reaches the sender, will cause the connection to be aborted since the sequence number would now be an exact match.

例では、リモートピアがRSTを生成しなかったが、それは上記の基準を満たすために失敗した場所(RSTシーケンス番号がウィンドウ内であったではなく、正確な予想シーケンス番号)チャレンジACKが返送されたときに、それはもはや持っていません伝送制御ブロック(TCB)は、この接続に関連し、したがって、[RFC0793]あたりとしては、リモートピアは、第二のRSTを返送します。第RSTのシーケンス番号は、受信ACKの確認応答番号に由来します。それは、送信者に到達した場合には、この第二RSTは、シーケンス番号が今完全に一致されるため、接続が中断されます。

A valid RST received out of order would still generate a challenge ACK in response. If this RST happens to be a genuine one, the other end would send an RST with an exact sequence number match that would cause the connection to be dropped.

有効RSTはまだ対応してチャレンジACKを生成するための外に受け取りました。このRSTが本物1であることを起こる場合は、もう一方の端は、接続が切断される原因となる正確なシーケンス番号が一致してRSTを送信します。

Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.

上記の緩和は、非増幅ACK交換を引き起こす可能性があることに注意してください。この懸念は、セクション10で説明されています。

4. Blind Reset Attack Using the SYN Bit
SYNビットを使用して4.ブラインドリセットアタック
4.1. Description of the Attack
4.1. 攻撃の説明

The analysis of the reset attack using the RST bit highlights another possible avenue for a blind attacker using a similar set of sequence number guessing. Instead of using the RST bit, an attacker can use the SYN bit with the exact same semantics to tear down a connection.

RSTビットを使用してリセット攻撃の分析は推測シーケンス番号の同様のセットを使用してブラインド攻撃者のための別の可能な道を強調しています。代わりにRSTビットを使用すると、攻撃者は、接続を切断するように正確に同じセマンティクスでSYNビットを使用することができます。

4.2. Mitigation
4.2. 緩和

[RFC0793] currently requires handling of a segment with the SYN bit set in the synchronized state to be as follows:

[RFC0793]は、現在、以下のように同期状態に設定されたビットSYNを有するセグメントの取り扱いを必要とします

1) If the SYN bit is set and the sequence number is outside the expected window, send an ACK back to the sender.

SYNビットがセットされ、シーケンス番号が期待されるウィンドウの外側である場合は1)、送信者にACKを送信します。

2) If the SYN bit is set and the sequence number is acceptable, i.e., (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then send a RST segment to the sender.

SYNビットがセットされ、シーケンス番号は、許容された場合2)、すなわち、(RCV.NXT <= SEG.SEQ <RCV.NXT + RCV.WND)、次いで送信者にRSTセグメントを送信します。

Instead, the handling of the SYN in the synchronized state SHOULD be performed as follows:

次のように代わりに、同期状態にSYNの取り扱いが行われるべきです。

1) If the SYN bit is set, irrespective of the sequence number, TCP MUST send an ACK (also referred to as challenge ACK) to the remote peer:

SYNビットがセットされている場合1)にかかわらず、シーケンス番号、TCPは、リモートピアに(また、チャレンジACKと称する)ACKを送信しなければなりません。

<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

<SEQ = SND.NXT> <ACK = RCV.NXT> <CTL = ACK>

After sending the acknowledgment, TCP MUST drop the unacceptable segment and stop processing further.

肯定応答を送信した後、TCPは、容認できないセグメントをドロップし、さらなる処理を停止する必要があります。

By sending an ACK, the remote peer is challenged to confirm the loss of the previous connection and the request to start a new connection. A legitimate peer, after restart, would not have a TCB in the synchronized state. Thus, when the ACK arrives, the peer should send a RST segment back with the sequence number derived from the ACK field that caused the RST.

ACKを送信することにより、リモートピアは、以前の接続が失われ、新しい接続を開始するための要求を確認するために挑戦しています。合法的なピアは、再起動後、同期した状態でのTCBを持っていないでしょう。 ACKが到着したときしたがって、ピアは、RSTを引き起こしたACKフィールドから誘導された配列番号バックRSTセグメントを送信しなければなりません。

This RST will confirm that the remote peer has indeed closed the previous connection. Upon receipt of a valid RST, the local TCP endpoint MUST terminate its connection. The local TCP endpoint should then rely on SYN retransmission from the remote end to re-establish the connection.

このRSTは、リモートピアが実際に以前の接続を閉じたことを確認します。有効RSTを受信すると、ローカルTCPエンドポイントは、その接続を終えなければなりません。ローカルTCPエンドポイントは、接続を再確立するために、リモートエンドからのSYN再送に依存している必要があります。

A spoofed SYN, on the other hand, will then have generated an additional ACK that the peer will discard as a duplicate ACK and will not affect the established connection.

スプーフィングされたSYNは、一方では、ピアは重複ACKとして破棄し、確立された接続に影響を与えないであろう追加のACKを生成しているであろう。

Note that this mitigation does leave one corner case un-handled, which will prevent the reset of a connection when it should be reset (i.e., it is a non-spoofed SYN wherein a peer really did restart). This problem occurs when the restarting host chooses the exact same IP address and port number that it was using prior to its restart. By chance, the restarted host must also choose an initial sequence number of exactly (RCV.NXT - 1) of the remote peer that is still in the established state. Such a case would cause the receiver to generate a "challenge" ACK as described above. But since the ACK would be within the outgoing connections window, the inbound ACK would be acceptable, and the sender of the SYN will do nothing with the response ACK. This sequence will continue as the SYN sender continually times out and retransmits the SYN until such time as the connection attempt fails.

この緩和は、それがリセットされるべきとき、接続のリセットを防止するケース未扱う一つのコーナーを残すないことに注意してください(すなわち、それはピアが実際に再起動しなかった前記非スプーフィングSYNです)。再起動のホストは、その再起動する前に使用していた正確に同じIPアドレスとポート番号を選択した場合、この問題が発生します。確立状態にあるリモートピアの - 偶然、再開ホストは、まさにの初期シーケンス番号(1 RCV.NXT)を選択する必要があります。このような場合は、上記のように、受信機が「挑戦」ACKを生成する原因となります。 ACKが発信接続ウィンドウ内にあるので、しかし、インバウンドACKは許容可能である、とSYNの送信者は、応答ACKを何もしません。このシーケンスは、継続的にタイムアウトにSYNの送信者として継続し、接続に失敗したような時間まで、SYNを再送します。

This corner case is a result of the [RFC0793] specification and is not introduced by these new requirements.

このコーナーケースは、[RFC0793]仕様の結果であり、これらの新しい要件によって導入されていません。

Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.

上記の緩和は、非増幅ACK交換を引き起こす可能性があることに注意してください。この懸念は、セクション10で説明されています。

5. Blind Data Injection Attack
5.ブラインドデータインジェクション攻撃
5.1. Description of the Attack
5.1. 攻撃の説明

A third type of attack is also highlighted by both the RST and SYN attacks. It is also possible to inject data into a TCP connection by simply guessing a sequence number within the current receive window of the victim. The ACK value of any data segment is considered valid as long as it does not acknowledge data ahead of the next segment to send. In other words, an ACK value is acceptable if it is ((SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the above inequality takes into account the fact that comparisons on TCP sequence and acknowledgment numbers is done using the modulo 32-bit arithmetic to accommodate the number wraparound. This means that an attacker has to guess two ACK values with every guessed sequence number so that the chances of successfully injecting data into a connection are 1 in ( 1/2 (2^32 / RCV.WND) * 2). Thus, the mean number of tries needed to inject data successfully is 1/2 (2*2^32/RWND) = 2^32/RCV.WND.

攻撃の第三のタイプは、RSTおよびSYN攻撃の両方によって強調表示されます。単に被害者の現在の受信ウィンドウ内のシーケンス番号を推測することにより、TCP接続にデータを挿入することも可能です。任意のデータ・セグメントのACK値は、それが送信するために先に次のセグメントのデータを承認しない限り有効であると考えられます。それは言い換えれば、ACK値が許容可能である((SND.UNA-(2 ^ 31-1))<= SEG.ACK <= SND.NXT)。 (2 ^ 31から1)上式では、アカウントにTCPシーケンスおよび確認応答番号に比較が番号ラップアラウンドを収容するモジュロ32ビット演算を使用して行われることを要します。これは、(* 1/2(2 ^ 32 / RCV.WND)2)攻撃者が正常に接続にデータを注入する可能性が1になるように、すべての推測シーケンス番号を持つ2つのACK値を推測しなければならないことを意味します。したがって、データを注入するために必要な試行の平均数は、正常1/2(2 * 2 ^ 32 / RWND)= 2 ^ 32 / RCV.WNDあります。

When an attacker successfully injects data into a connection, the data will sit in the receiver's re-assembly queue until the peer sends enough data to bridge the gap between the RCV.NXT value and the injected data. At that point, one of two things will occur:

攻撃者が正常に接続にデータを注入する際にピアがRCV.NXT値と注入データとの間のギャップを埋めるために十分なデータを送信するまで、データは、受信機の再組立キューに座るであろう。この時点で、2つのうちの1つが発生します。

1) A packet war will ensue with the receiver indicating that it has received data up until RCV.NXT (which includes the attacker's data) and the sender sending an ACK with an acknowledgment number less than RCV.NXT.

1)パケット戦争は、それが攻撃者のデータを含んRCV.NXT()とRCV.NXT未満確認応答番号のACKを送信する送信側までデータを受信したことを示す受信機と続いて起こるであろう。

2) The sender will send enough data to the peer that will move RCV.NXT even further along past the injected data.

2)送信者は注入データ過去に沿ってさらにRCV.NXTを移動するピアに十分なデータを送信します。

Depending upon the TCP implementation in question and the TCP traffic characteristics at that time, data corruption may result. In case (a), the connection will eventually be reset by one of the sides unless the sender produces more data that will transform the ACK war into case (b). The reset will usually occur via User Time Out (UTO) (see section 4.2.3.5 of [RFC1122]).

質問とその時点でのTCPトラフィック特性におけるTCPの実装に応じて、データが破損する恐れがあります。送信側がケース(B)にACK戦争を変換しますより多くのデータを生成しない限り、(a)の場合、接続は、最終的に両側のいずれかによってリセットされます。リセットは、通常、([RFC1122]のセクション4.2.3.5を参照)ユーザータイムアウト(UTO)を介して行われます。

Note that the protections illustrated in this section neither cause an ACK war nor prevent one from occurring if data is actually injected into a connection. The ACK war is a product of the attack itself and cannot be prevented (other than by preventing the data from being injected).

このセクションに示されている保護はACK戦争を引き起こすことも、データが実際の接続に注入された場合に発生するものを防ぐどちらもあることに注意してください。 ACK戦争攻撃自体の積であり、(注入されるからデータを防止することによって以外)を防止することができません。

5.2. Mitigation
5.2. 緩和

All TCP stacks MAY implement the following mitigation. TCP stacks that implement this mitigation MUST add an additional input check to any incoming segment. The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.

すべてのTCPスタックは、次の緩和策を実施することができます。この緩和策を実装するTCPスタックは、すべての着信セグメントに追加の入力チェックを追加しなければなりません。 ACK値は、それが( - MAX.SND.WND)<= SEG.ACK <= SND.NXT(SND.UNA)の範囲内にある場合にのみ許容されると考えられます。そのACK値が上記条件を満たしていないすべての受信セグメントを捨てなければならないとACKを返送しました。 「ACKが重複(SEG.ACK <SND.UNA)であればACKがまだ(SEG送信されていない何かを承認した場合、それは無視することができます。これは、72ページのRFC 793(第五のチェックが)言うことに注意する必要があります。 ACK> SND.NXT)、次いで「ACKを送信するセグメントをドロップし、そして戻り。上記「無視」は、着信データ・セグメントの処理は、ACK値が許容されるように扱われることを意味する、継続することを意味します。 MAX.SND.WND)<= SEG.ACK <= SND - 任意ACK <SND.UNAは、範囲((SND.UNAにある代わりにのみACKを受け付けられないので、この緩和は、ACKチェックがより厳格になります。 NXTは)を介して取得します。

A new state variable MAX.SND.WND is defined as the largest window that the local sender has ever received from its peer. This window may be scaled to a value larger than 65,535 bytes ([RFC1323]). This small check will reduce the vulnerability to an attacker guessing a valid sequence number, since, not only one must guess the in-window sequence number, but also guess a proper ACK value within a scoped range. This mitigation reduces, but does not eliminate, the ability to generate false segments. It does however reduce the probability that invalid data will be injected.

新しい状態変数MAX.SND.WNDは、ローカル送信者が、これまでそのピアから受信した最大のウィンドウとして定義されます。このウィンドウには、65,535バイト([RFC1323])よりも大きい値にスケーリングすることができます。この小さなチェックは、1つの中に、ウィンドウのシーケンス番号を推測しなければならないだけでなく、以来、有効なシーケンス番号を推測攻撃に対する脆弱性を軽減するだけでなく、スコープの範囲内の適切なACK値を推測します。この緩和は減りますが、偽のセグメントを生成する能力がなくなるわけではありません。しかし、無効なデータが注入される確率を減らすん。

Implementations can also chose to hard code the MAX.SND.WND value to the maximum permissible window size, i.e., 65535 in the absence of window scaling. In the presence of the window scaling option, the value becomes (MAX.SND.WND << Snd.Wind.Scale).

実装は、ウィンドウ・スケーリングの不在下で65535、すなわち、最大許容ウインドウサイズにハードコードにMAX.SND.WND値を選択することができます。ウィンドウスケーリングオプションの存在下では、値は(MAX.SND.WND << Snd.Wind.Scale)となります。

This mitigation also helps in improving robustness on accepting spoofed FIN segments (FIN attacks). Among other things, this mitigation requires that the attacker also needs to get the acknowledgment number to fall in the range mentioned above in order to successfully spoof a FIN segment leading to the closure of the connection. Thus, this mitigation greatly improves the robustness to spoofed FIN segments.

この緩和はまた、偽装されたFINセグメント(FIN攻撃を)受け入れることで堅牢性を改善するのに役立ちます。とりわけ、この緩和策は、攻撃者はまた、成功した接続の閉鎖につながるFINセグメントを偽装するために、上記の範囲内に収まるように確認番号を取得する必要があることが必要です。したがって、この緩和が大きく偽装FINセグメントに対するロバスト性を向上させることができます。

Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.

上記の緩和は、非増幅ACK交換を引き起こす可能性があることに注意してください。この懸念は、セクション10で説明されています。

6. Suggested Mitigation Strengths
6.推奨緩和強み

As described in the above sections, recommendation levels for RST, SYN, and DATA are tagged as SHOULD, SHOULD, and MAY, respectively. The reason that DATA mitigation is tagged as MAY, even though it increased the TCP robustness in general is because, the DATA injection is perceived to be more difficult (twice as unlikely) when compared to RST and SYN counterparts. However, it needs to be noted that all the suggested mitigations improve TCP's robustness in general and hence the choice of implementing some or all mitigations recommended in the document is purely left to the implementer.

上記のセクションで説明したように、RST、SYN、およびデータのための推奨レベルは、それぞれべきでなければならず、MAYとしてタグ付けされています。 RSTとSYN対応物と比較した場合、データ挿入がより困難(二倍の可能性は低い)であると認識されている、ため、データの緩和は、それが一般的にTCPの堅牢性を増加させたにも関わらず、MAYとしてタグ付けされていることを理由です。しかし、それはすべての提案緩和策は、一般的にはTCPの堅牢性を向上させることに注意する必要があり、したがって、文書で推奨の一部またはすべての緩和策を実装するの選択は実装者に、純粋に左です。

7. ACK Throttling
7. ACKスロットリング

In order to alleviate multiple RSTs/SYNs from triggering multiple challenge ACKs, an ACK throttling mechanism is suggested as follows:

次のように複数のチャレンジACKをトリガから複数のRST /のSYNを軽減するために、ACKの絞り機構が提案されています。

1) The system administrator can configure the number of challenge ACKs that can be sent out in a given interval. For example, in any 5 second window, no more than 10 challenge ACKs should be sent.

1)システム管理者は、所定の間隔で送信することができるチャレンジACKの数を設定することができます。例えば、任意の5秒のウィンドウで、せいぜい10個のチャレンジACKは送信されるべきではありません。

2) The values for both the time and number of ACKs SHOULD be tunable by the system administrator to accommodate different perceived levels of threat and/or system resources.

2)時間及びACKの数の両方の値は脅威及び/又はシステムリソースの異なる知覚レベルに対応するために、システム管理者によって調整可能であるべきです。

It should be noted that these numbers are empirical in nature and have been obtained from the RST throttling mechanisms existing in some implementations. Also, note that no timer is needed to implement the above mechanism, instead a timestamp and a counter can be used.

これらの数字は自然の中で経験しているし、いくつかの実装では、既存のRSTスロットリングのメカニズムから得られていることに留意すべきです。また、代わりにタイムスタンプとカウンタを使用することができ、何のタイマーが上記のメカニズムを実装するために必要ではないことに注意してください。

An implementation SHOULD include an ACK throttling mechanism to be conservative. While we have not encountered a case where the lack of ACK throttling can be exploited, as a fail-safe mechanism we recommend its use. An implementation may take an excessive number of invocations of the throttling mechanism as an indication that network conditions are unusual or hostile.

実装は、保守的であることがACK絞り機構を含むべきです。我々はACKスロットリングの欠如を活用することができる場合は発生していませんが、フェイルセーフメカニズムとして、私たちはその使用をお勧めします。インプリメンテーションは、ネットワークの状態が異常または敵対的であることを示すように絞り機構の呼び出しの過剰な数を取ることができます。

An administrator who is more concerned about protecting his bandwidth and CPU utilization may set smaller ACK throttling values whereas an administrator who is more interested in faster cleanup of stale connections (i.e., concerned about excess TCP state) may decide to set a higher value thus allowing more RST's to be processed in any given time period.

失効した接続(すなわち、過剰TCPの状態が心配)できるので、より高い値を設定するように決定することができるのより迅速なクリーンアップでより興味を持っている管理者に対し、小さいACKの調整値を設定することが彼の帯域幅とCPU使用率の保護の詳細懸念している管理者より多くのRSTのは、任意の与えられた時間内に処理されます。

The time limit SHOULD be tunable to help timeout brute force attacks faster than a potential legitimate flood of RSTs.

制限時間は速いのRSTの潜在的な合法的な洪水よりもタイムアウトブルートフォース攻撃を助けるために調整可能であるべきです。

8. Backward Compatibility and Other Considerations
8.下位互換性およびその他の考慮事項

All of the new required mitigation techniques in this document are totally compatible with existing ([RFC0793]) compliant TCP implementations as this document introduces no new assumptions or conditions.

このドキュメントは新しい仮定や条件を導入していないとして、この文書の新しい必須緩和技術のすべては、既存の([RFC0793])に準拠したTCP実装と完全に互換性があります。

There is a corner scenario in the above mitigations that will require more than one round-trip time to successfully abort the connection as per the figure below. This scenario is similar to the one in which the original RST was lost in the network.

コーナーシナリオは成功し、次の図のとおりに接続を中止するには、複数のラウンドトリップ時間が必要になります上記の緩和策です。このシナリオでは、元のRSTがネットワークで失われたものと類似しています。

TCP A TCP B 1.a. ESTAB <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTAB b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTAB c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED 2. ESTAB --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED (ACK for 1.a) ... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED 3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED (for 1.c) ... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE 4.a. ESTAB <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A b. ESTAB --> <SEQ=101><ACK=500><CTL=ACK> c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED 5. RESPONSE arrives at A, but dropped since its outside of window. 6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A 7. CLOSED CLOSED

TCP TCP Bは1.A. ESTAB < - <SEQ = 300> <ACK = 101> <CTL = ACK> <DATA> < - ESTABのB。 (遅延)... <SEQ = 400> <ACK = 101> <CTL = ACK> <DATA> < - ESTABのC。 (飛行中)... <SEQ = 500> <ACK = 101> <CTL = RST> < - CLOSED 2 ESTAB - > <SEQ = 101> <ACK = 400> <CTL = ACK> - > CLOSED(1.A用ACK)... <SEQ = 400> <ACK = 0> <CTL = RST> < - CLOSEDを3 CHALLENGE - > <SEQ = 101> <ACK = 400> <CTL = ACK > - >閉じた(1.C用)... <SEQ = 400> <ACK = 0> <CTL = RST> < - RESPONSEの4.A. ESTAB < - <SEQ = 400> <ACK = 101> <CTL = ACK> <データ> 1.B Bに到達します。 ESTAB - > <SEQ = 101> <ACK = 500> <CTL = ACK> C。 (飛行中)... <SEQ = 500> <ACK = 0> <CTL = RST> < - 5.応答がAに到達CLOSEDが、ウィンドウのその外側ためドロップ。 6. ESTAB < - <SEQ = 500> <ACK = 0> <CTL = RST> 4.C 7. CLOSED CLOSEDに到達します

For the mitigation to be maximally effective against the vulnerabilities discussed in this document, both ends of the TCP connection need to have the fix. Although, having the mitigations at one end might prevent that end from being exposed to the attack, the connection is still vulnerable at the other end.

緩和は、この文書で説明する脆弱性に対する最大限に有効にするには、TCP接続の両端には修正が必要です。 、一端に緩和策を持つことが攻撃にさらされることから、その終わりを防ぐかもしれませんが、接続はまだもう一方の端に脆弱です。

9. Middlebox Considerations
9.ミドルの考慮事項
9.1. Middlebox That Resend RSTs
9.1. ミドル再送信のRSTこと

Consider a middlebox M-B tracking connections between two TCP end hosts E-A and E-C. If E-C sends a RST with a sequence number that is within the window but not an exact match to reset the connection and M-B does not have the fix recommended in this document, it may clear the connection and forward the RST to E-A saving an incorrect sequence number. If E-A does not have the fix, the connection would get cleared as required. However, if E-A does have the required fix, it will send a challenge ACK to E-C. M-B, being a middlebox, may intercept this ACK and resend the RST on behalf of E-C with the old sequence number. This RST will, again, not be acceptable and may trigger a challenge ACK.

2つのTCPエンドホストE-AとE-Cとの間のミドルM-Bトラッキング接続を考えます。 ECがウィンドウ内にあるシーケンス番号とのRSTを送信ではなく、接続をリセットするために完全に一致し、MBは、このドキュメントで推奨修正を持っていない、それは接続を解除し、不正なシーケンスを保存EAにRSTを転送することができるならば数。 E-Aが修正されていない場合、必要に応じて、接続がクリアになるだろう。 E-Aは、必要な修正を持っていない場合は、それはE-CにチャレンジACKを送信します。 M-Bは、ミドルボックスであり、このACKを傍受し、古いシーケンス番号を有するE-Cの代わりにRSTを再送信することができます。このRSTは、再び、許容できないであろうと挑戦ACKをトリガすることができます。

The above situation may result in a RST/ACK war. However, we believe that if such a case exists in the Internet, the middlebox is generating packets a conformant TCP endpoint would not generate. [RFC0793] dictates that the sequence number of a RST has to be derived from the acknowledgment number of the incoming ACK segment. It is outside the scope of this document to suggest mitigations to the ill-behaved middleboxes.

上記の状況は、RST / ACK戦争をもたらすことができます。しかし、我々はそのような場合は、インターネットに存在する場合、ミドルは準拠TCPエンドポイントが生成しないパケットを生成していると信じています。 [RFC0793]はRSTのシーケンス番号が受信ACKセグメントの確認応答番号から導出されなければならないことを指示します。それは行儀の悪いミドルボックスに緩和策を提案するために、このドキュメントの範囲外です。

Consider a similar scenario where the RST from M-B to E-A gets lost, E-A will continue to hold the connection and E-A might send an ACK an arbitrary time later after the connection state was destroyed at M-B. For this case, M-B will have to cache the RST for an arbitrary amount of time until it is confirmed that the connection has been cleared at E-A.

E-AとM-BからのRSTが失わ同様のシナリオを検討して、E-Aは、接続状態がM-Bで破壊された後、接続およびE-Aは、任意の時間後にACKを送信することがあります保持し続けます。この場合には、M-Bは、接続がE-Aでクリアされたことが確認されるまでの時間の任意の量のためにRSTをキャッシュする必要があります。

9.2. Middleboxes That Advance Sequence Numbers
9.2. Middleboxesアドバンスシーケンス番号

Some middleboxes may compute RST sequence numbers at the higher end of the acceptable window. The scenario is the same as the earlier case, but in this case instead of sending the cached RST, the middlebox (M-B) sends a RST that computes its sequence number as the sum of the acknowledgment field in the ACK and the window advertised by the ACK that was sent by E-A to challenge the RST as depicted below. The difference in the sequence numbers between step 1 and 2 below is due to data lost in the network.

いくつかのミドルボックスは、許容可能なウィンドウの高い終わりRSTシーケンス番号を計算することができます。シナリオは、以前の場合と同じであるが、代わりにキャッシュされたRSTを送信し、この場合には、ミドルボックス(MB)は、によって通知ACKで肯定応答フィールドの和と窓としてのシーケンス番号を計算RSTを送信します。下に示されているようにRSTに挑戦するEAによって送信されたACK。ステップ1と2の間に以下のシーケンス番号の差がネットワークで失われたデータによるものです。

TCP A Middlebox

TCP Aミドル

1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED
1. ESTABLISHED < - <SEQ = 500> <ACK = 100> <CTL = RST> < - CLOSED
2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
2. ESTABLISHED - > <SEQ = 100> <ACK = 300> <AND = 500> <CTL = ACK> - > CLOSED
3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
3. ESTABLISHED < - <SEQ = 800> <ACK = 100> <CTL = RST> < - CLOSED
4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
4. ESTABLISHED - > <SEQ = 100> <ACK = 300> <AND = 500> <CTL = ACK> - > CLOSED
5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
5. ESTABLISHED < - <SEQ = 800> <ACK = 100> <CTL = RST> < - CLOSED

Although the authors are not aware of an implementation that does the above, it could be mitigated by implementing the ACK throttling mechanism described earlier.

著者らは、上記の処理を行い、実装を認識していませんが、それは前述のACKの絞り機構を実装することによって軽減することができます。

9.3. Middleboxes That Drop the Challenge ACK
9.3. チャレンジACKをドロップのMiddleboxes

It also needs to be noted that, some middleboxes (Firewalls/NATs) that don't have the fix recommended in the document, may drop the challenge ACK. This can happen because, the original RST segment that was in window had already cleared the flow state pertaining to the TCP connection in the middlebox. In such cases, the end hosts that have implemented the RST mitigation described in this document, will have the TCP connection left open. This is a corner case and can go away if the middlebox is conformant with the changes proposed in this document.

また、文書で推奨修正を持っていないいくつかのミドルボックス(ファイアウォール/ NATのは)、チャレンジACKをドロップする可能性があることに注意する必要があります。ウィンドウにあったオリジナルのRSTセグメントがすでにミドルでのTCP接続に関連するフロー状態をクリアしていたが、これは起こることができます。このような場合には、この文書で説明RSTの緩和を実施しているエンドホストは、開いたままのTCPコネクションを持つことになります。これは、コーナーケースで、ミドルは、この文書で提案された変更に準拠している場合は離れて行くことができます。

10. Security Considerations
10.セキュリティの考慮事項

These changes to the TCP state machine do NOT protect an implementation from on-path attacks. It also needs to be emphasized that while mitigations within this document make it harder for off-path attackers to inject segments, it does NOT make it impossible. The only way to fully protect a TCP connection from both on- and off-path attacks is by using either IPsec Authentication Header (AH) [RFC4302] or IPsec Encapsulating Security Payload (ESP) [RFC4303].

TCPステートマシンにこれらの変更は、上のパス攻撃から実装を保護することはできません。また、この文書内の緩和策は、それが難しく、オフパス攻撃者がセグメントを注入するために作る一方で、それはそれは不可能せないことを強調する必要があります。完全にオンとオフパス攻撃の両方からのTCP接続を保護するための唯一の方法は、IPsec認証ヘッダ(AH)[RFC4302]やIPsecカプセル化セキュリティペイロード(ESP)[RFC4303]のいずれかを使用することです。

Implementers also should be aware that the attacks detailed in this specification are not the only attacks available to an off-path attacker and that the counter measures described herein are not a comprehensive defense against such attacks.

実装はまた、本明細書に詳述攻撃が本明細書に記載の対策オフパス攻撃者とその利用可能な唯一の攻撃は、攻撃に対する包括的な防御されていないていないことに注意すべきです。

In particular, administrators should be aware that forged ICMP messages provide off-path attackers the opportunity to disrupt connections or degrade service. Such attacks may be subject to even less scrutiny than the TCP attacks addressed here, especially in stacks not tuned for hostile environments. It is important to note that some ICMP messages, validated or not, are key to the proper function of TCP. Those ICMP messages used to properly set the path maximum transmission unit are the most obvious example. There are a variety of ways to choose which, if any, ICMP messages to trust in the presence of off-path attackers and choosing between them depends on the assumptions and guarantees developers and administrators can make about their network. This specification does not attempt to do more than note this and related issues. Unless implementers address spoofed ICMP messages [RFC5927], the mitigations specified in this document may not provide the desired protection level.

具体的には、管理者が偽造したICMPメッセージは、パスがオフの接続を妨害するか、サービスを低下させる機会を攻撃者が提供していることに注意する必要があります。このような攻撃は、TCP攻撃は特に苛酷な環境用に調整されていないスタックに、ここで扱わよりもさらに少ない精査を受ける可能性があります。検証されたりしませいくつかのICMPメッセージは、TCPの適切な機能に重要であることに注意することが重要です。適切経路最大送信ユニットを設定するために使用されるものICMPメッセージは、最も明白な例です。開発者や管理者がネットワークについて行うことができます仮定や保証に依存し、もしあれば、オフ・パス攻撃者の存在に信頼するようにICMPメッセージとそれらの間の選択を選択するためのさまざまな方法があります。この仕様は、これと関連した問題点に注意してください以上のことを行うためにしようとしません。実装者は、偽装されたICMPメッセージ[RFC5927]を対処しない限り、この文書で指定された緩和策は、所望の保護レベルを提供することはできません。

In any case, this RFC details only part of a complete strategy to prevent off-path attackers from disrupting services that use TCP. Administrators and implementers should consider the other attack vectors and determine appropriate mitigations in securing their systems.

いずれにせよ、このRFCはTCPを使用するサービスを中断することから、オフパス攻撃を防ぐための完全な戦略の一部のみを詳述します。管理者と実装者は、他の攻撃ベクトルを考慮し、自社のシステムを確保するには、適切な緩和策を決定する必要があります。

Another notable consideration is that a reflector attack is possible with the required RST/SYN mitigation techniques. In this attack, an off-path attacker can cause a victim to send an ACK segment for each spoofed RST/SYN segment that lies within the current receive window of the victim. It should be noted, however, that this does not cause any amplification since the attacker must generate a segment for each one that the victim will generate.

もう一つの注目すべき検討事項は、反射攻撃が必要とRST / SYN軽減手法で可能であるということです。この攻撃では、オフ・パス攻撃者が被害者の現在の受信ウィンドウ内にある各偽装されたRST / SYNセグメントのACKセグメントを送信するために被害者を引き起こす可能性があります。攻撃者は被害者が発生します、それぞれにセグメントを生成しなければならないので、これは任意の増幅を生じないことに留意すべきです。

11. Contributors
11.協力者

Mitesh Dalal and Amol Khare of Cisco Systems came up with the solution for the RST/SYN attacks. Anantha Ramaiah and Randall Stewart of Cisco Systems discovered the data injection vulnerability and together with Patrick Mahan and Peter Lei of Cisco Systems found solutions for the same. Paul Goyette, Mark Baushke, Frank Kastenholz, Art Stine, and David Wang of Juniper Networks provided the insight that apart from RSTs, SYNs could also result in formidable attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of Wind River Systems, and Xiaodan Tang of QNX Software along with the folks above helped in ratifying and testing the interoperability of the suggested solutions.

Mitesh DalalとシスコシステムズのKhareて、Amolは、RST / SYN攻撃のための解決策を考え出しました。 Anantha Ramaiahとシスコシステムズのランドール・スチュワートは、データインジェクションの脆弱性を発見し、一緒にパトリック・マハンとシスコシステムズのピーター・レイと同じのための解決策を見つけました。ポール・Goyette、マーク・Baushke、フランクKastenholzと、アートスタイン、およびジュニパーネットワークスのデイヴィッド王は離れてのRSTから、SYNのも手強い攻撃につながる可能性の洞察を提供しました。提案ソリューションの相互運用性を批准し、テストで助けた以上の人々と一緒に、シスコシステムズ、清LiとウインドリバーのPreetyプリ、およびQNXソフトウエアのXiaodan唐のShrirang BAGE。

12. Acknowledgments
12.謝辞

Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra Murphy, Brian Carpenter, Cullen Jennings, and other members of the tcpm WG for suggestions and comments. ACK throttling was introduced to this document by combining the suggestions from the tcpm working group.

マーク・オールマン、テッド・フェーバー、スティーブBellovin氏、バーン・パクソン、アリソンマンキン、シャラドAhlawat、ダミールRajnovic、ジョンウォン、ジョー・タッチ、アルフレッドHoenes、アンドレOppermannの、フェルナンドGont、サンドラ・マーフィー、ブライアン・カーペンター、カレン・ジェニングス、および他に感謝提案やコメントのためtcpm WGのメンバー。 ACKスロットリングはtcpmワーキンググループからの提案を組み合わせることにより、本文書に紹介されました。

13. References
13.参考文献
13.1. Normative References
13.1. 引用規格

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

[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

13.2. Informative References
13.2. 参考文献

[Medina05] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communication Review, 35(2), April 2005, <http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps>.

[Medina05]メディナ、A.、オールマン、M.、およびS.フロイド、 "インターネットにおけるトランスポートプロトコルの進化を測定する"、ACMコンピュータコミュニケーションレビュー、35(2)、2005年4月、<のhttp:// WWW。 > icir.org/mallman/papers/tcp-evo-ccr05.ps。

[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - Vulnerability Issues in TCP".

[NISCC] NISCC、 "NISCCの脆弱性の諮問236929 - TCPの脆弱性の問題"。

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

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

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

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

[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.

[RFC1948] Bellovin氏、S.、 "シーケンス番号攻撃からの保護"、RFC 1948、1996年5月。

[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。

[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4(BGP-4)"、RFC 4271、2006年1月。

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

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

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

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

[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.

[RFC4953]タッチ、J.、RFC 4953、2007年7月 "なりすまし攻撃に対するTCPを防衛"。

[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.

[RFC5927] Gont、F.、 "TCPに対するICMP攻撃"、RFC 5927、2010年7月。

[SITW] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, <http://cansecwest.com/csw04archive.html>.

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

[TSVWG-PORT] Larsen, M. and F. Gont, "Transport Protocol Port Randomization Recommendations", Work in Progress, August 2010.

[TSVWG-PORT]ラーセン、M.とF. Gont、 "トランスポートプロトコルポートのランダム化に関する推奨事項"、進歩、2010年8月での作業。

Authors' Addresses

著者のアドレス

Anantha Ramaiah Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA

Anantha Ramaiahシスコシステムズ170タスマン・ドライブサンノゼ、CA 95134 USA

Phone: +1 (408) 525-6486 EMail: ananth@cisco.com

電話:+1(408)525-6486 Eメール:ananth@cisco.com

Randall R. Stewart Huawei 148 Crystal Cove Ct Chapin, SC 29036 USA

ランドールR.スチュワート華為148クリスタルコーブのCtチャピン、SC 29036 USA

Phone: +1 (803) 345-0369 EMail: rstewart@huawei.com

電話:+1(803)345-0369 Eメール:rstewart@huawei.com

Mitesh Dalal Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA

Mitesh Dalalシスコシステムズ170タスマン・ドライブサンノゼ、CA 95134 USA

Phone: +1 (408) 853-5257 EMail: mdalal@cisco.com

電話:+1(408)853-5257 Eメール:mdalal@cisco.com