[要約] 要約：RFC 5961は、TCPの盲目的な攻撃に対する耐性を向上させるための提案をまとめたものです。 目的：このRFCの目的は、TCPのセキュリティを向上させ、盲目的な攻撃からの保護を強化することです。
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
Window攻撃を盲目にするためのTCPの堅牢性の向上
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またはBorder Gateway Protocol（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アプリケーションの多くは、予測可能なIPアドレスとポートを備えている傾向があり、4タプル（4タプルはRFC 793で言及されているソケットペアと同じ）が推測されるのとはるかに簡単です。4タプルを正しく推測した後、攻撃者は、最初のビットセット、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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ソースと宛先アドレス、およびソースポートと宛先ポート（このドキュメントの4タプル値と呼ばれる）を偽造することにより、オフパス攻撃者がTCPパケットを作成します。ターゲットを絞ったTCPエンドポイントは、そのようなパケットを既存のTCP接続に関連付けます。この4タプル値を推測することは、攻撃者にとって必ずしも簡単ではないことに注意する必要があります。ただし、いずれかのエンドポイントで同じセットのポートを使用する傾向があるアプリケーション（BGP [RFC4271]など）がいくつかあり、4タプル値を正しく推測する確率がはるかに容易になります。攻撃者が4タプル値を推測することに成功した場合、3種類の注射攻撃の1つが長命の接続に対して繰り広げられる可能性があります。RST-攻撃者が接続を取り壊すことを望んでRSTセグメントを注入する場合。ここでの「RSTセグメント」とは、RST BIT SETのTCPセグメントを指します。Syn-攻撃者がSynを注入して、受信者にピアが再起動したと信じることを望んでいるため、接続状態を取り壊します。ここでの「Synセグメント」とは、Synビットセットを備えたTCPセグメントを指します。データ - 攻撃者がデータセグメントを注入して、送信の内容を破壊しようとする場合。ここでの「データセグメント」とは、データを含むTCPセグメントを指します。
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接続の例は、長寿命になる傾向があるものであり、接続エンドポイントを決定できる場所です。TCPMD5[RFC2385]のような補助防止防止保護メカニズムが展開できない場合。これらの緩和は、他の場合に実装される場合があります。
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:
最初の攻撃に焦点を当てて、この攻撃をより詳細に調べて、それがどのように機能し、このドキュメントが問題にどのように対処するかについての概要を把握します。この攻撃のために、目標は、攻撃者が接続の2つのエンドポイントの1つを引き起こし、接続状態を誤って取り壊し、効果的に接続を中止することです。注意すべき重要なことの1つは、攻撃が成功するためには、Rの最初のものが有効な受信ウィンドウにある必要があることです。また、受信ウィンドウは、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セグメントを提示しようとするための出発点となります。ランダム値は、開始シーケンス番号を推測するために使用できます。
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 SETと推測された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のセグメント処理ルールをわずかに強化することができ、そのような攻撃を達成するのがはるかに困難になります。受信機が着信RSGセグメントを調べ、シーケンス番号が次に予想されるシーケンス番号と正確に一致することを検証した場合、そのような攻撃は[SITW]で概説されているよりもはるかに困難になります（つまり、攻撃者は1/2を生成する必要がありますシーケンススペース全体、平均して）。このドキュメントでは、TCPのセグメント処理ルール内で変更する必要があるものの正確な詳細について、3種類すべての攻撃（RST、Syn、およびデータ）を緩和します。
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、またはデータ）を正常に挿入するために、過去には、このような攻撃を可能にするためにシーケンス空間全体（つまり、2^32）全体が利用可能であると考えられていました。[SITW]は、この仮定が正しくなく、（1/2 * 2^32）パケットの代わりに（ランダム分布を仮定）、（1/2 *（2^32/window））パケットが必要であることを実証しました。言い換えれば、最初のセグメントを注入するために必要な試行の平均数は、前に想定された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のウィンドウサイズの場合、TCPレシーバーに受け入れられるTCPセグメントを「スプーフィング」するために、平均65,536パケットを送信する必要があることがわかります。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接続の持続時間である追加の依存関係が1つあります。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]を参照してください。また、[TSVWG-PORT]および[RFC1948]で示唆されているように、ポートランダム化と初期シーケンス数（ISN）ランダム化が、オフパス攻撃に対するTCP接続の堅牢性を改善するのに役立つことも強調する必要があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。TCP用語は、[RFC0793]に記載されているように解釈する必要があります。
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フィールド[シーケンス番号]をチェックすることにより検証されます。シーケンス番号がウィンドウにある場合、リセットは有効です。Syn-Sent状態（最初のSynに応じてRECOMEDを受け取った最初の状態）では、ACKフィールドがSynを認めた場合、RSTは許容されます。
[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.
1) 最初のビットが設定され、シーケンス番号が現在の受信ウィンドウ（seg.seq <= rcv.nxt || seg.seq> rcv.nxt rcv.wnd）の外側にある場合、セグメントを静かにドロップします。
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.
2) RSTビットが設定され、シーケンス番号が許容される場合、つまり（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.
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.
2) RSTビットが設定され、シーケンス番号が次の予想シーケンス番号（RCV.NXT）と正確に一致する場合、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):
3) 最初のビットが設定されており、シーケンス番号が次の予想シーケンス値と正確に一致しない場合、現在の受信ウィンドウ内にある場合（rcv.nxt <seg.seq <rcv.nxt rcv.wnd）、TCPは確認を送信する必要があります（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フィールド[シーケンス番号]をチェックすることにより検証されます。リセットは、そのシーケンス番号が次の予想シーケンス番号と正確に一致する場合に有効です。最初に到着し、そのシーケンス番号フィールドが次の予想されるシーケンス番号と一致しないが、ウィンドウ内にある場合、レシーバーはACKを生成する必要があります。他のすべてのケースでは、配列場が一致せず、ウィンドウの外側にある場合、受信者はセグメントを静かに廃棄する必要があります。
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.
Syn-Sent状態（最初のSynに応じてRECOMEDを受け取った最初の状態）では、ACKフィールドが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シーケンス番号はウィンドウ内でしたが、正確な予想シーケンス番号ではありません）。この接続に関連する送信制御ブロック（TCB）、したがって[RFC0793]に従って、リモートピアは2回目のRを送信します。2番目のRのシーケンス番号は、着信ACKの確認番号から導き出されます。この2回目のRは、送信者に到達した場合、シーケンス番号が正確な一致になるため、接続が中止されます。
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.
有効な最初に故障したことは、それに応じてチャレンジACKを生成します。このRが本物のものである場合、もう一方の端は、接続がドロップされる正確なシーケンス番号マッチでRSTを送信します。
Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.
上記の緩和は、非増幅ACK交換を引き起こす可能性があることに注意してください。この懸念はセクション10で説明されています。
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ビットを使用したリセット攻撃の分析は、同様のシーケンス番号推測を使用して、ブラインド攻撃者の別の可能な手段を強調しています。攻撃者は、最初のビットを使用する代わりに、まったく同じセマンティクスを使用してSynビットを使用して接続を取り壊すことができます。
[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.
1) Synビットが設定され、シーケンス番号が予想されるウィンドウの外側にある場合は、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.
2) synビットが設定されており、シーケンス番号が許容される場合、つまり（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:
1) Synビットが設定されている場合、シーケンス番号に関係なく、TCPはACK（チャレンジ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.
このRは、リモートピアが実際に以前の接続を閉じたことを確認します。有効な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.
この緩和は、1つのコーナーケースがハンドルされていないため、リセットする必要がある場合に接続のリセットを防ぐことに注意してください（つまり、ピアが本当に再起動したのは、スプーフィングされていないSynです）。この問題は、再起動ホストが再起動前に使用していたまったく同じIPアドレスとポート番号を選択したときに発生します。偶然にも、再起動されたホストは、まだ確立された状態にあるリモートピアの正確な（rcv.nxt -1）の初期シーケンス数（rcv.nxt -1）を選択する必要があります。このような場合、上記のようにレシーバーが「チャレンジ」ACKを生成します。しかし、ACKは発信接続ウィンドウ内にあるため、インバウンドACKは受け入れられ、Synの送信者は応答ACKで何もしません。このシーケンスは、Syn Senderが継続的にタイムアウトし、接続試行が失敗するまで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で説明されています。
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.
3番目のタイプの攻撃は、RST攻撃とSyn攻撃の両方によって強調されています。また、被害者の現在の受信ウィンドウ内のシーケンス番号を推測するだけで、データをTCP接続に注入することもできます。データセグメントのACK値は、送信する次のセグメントの前にデータを確認しない限り、有効と見なされます。言い換えれば、（（snd.una-（2^31-1））<= seg.ack <= snd.nxt）である場合、ACK値は許容されます。上記の不平等の（2^31-1）は、TCPシーケンスと確認番号の比較がModulo 32ビット算術を使用して行われ、数字のラップに対応するという事実を考慮しています。これは、攻撃者が推測されたシーケンス番号ごとに2つのACK値を推測する必要があるため、データを接続に正常に注入する可能性が1インチ（1/2（2^32 / rcv.wnd） * 2）になることを意味します。したがって、データを正常に注入するために必要な試行の平均数は、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トラフィック特性に応じて、データの破損が生じる可能性があります。ケース（a）では、送信者がACK戦争をケース（b）に変換するより多くのデータを生成しない限り、接続は最終的に側面の1つによってリセットされます。リセットは通常、ユーザータイムアウト（UTO）を介して発生します（[RFC1122]のセクション4.2.3.5を参照）。
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戦争は攻撃自体の産物であり、防止することはできません（データが注入されないようにすることを除く）。
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値は、（（snd.una -max.snd.wnd）<= seg.ack <= snd.nxt）の範囲にある場合にのみ、許容できると見なされます。ACK値が上記の条件を満たさないすべての着信セグメントは廃棄し、ACKを送り返す必要があります。72ページ（5回目のチェック）のRFC 793（ACKが重複している場合（seg.ack <snd.una）である場合、ACKがまだ送信されていないもの（seg。ACK> SND.NXT）次にACKを送信し、セグメントをドロップして戻ります」。上記の「無視された」は、着信データセグメントの処理が継続することを意味します。つまり、ACK値は許容可能であると扱われます。この緩和により、ACK <SND.UNAは受け入れられないため、ACKチェックはより厳格になり、代わりに範囲内にあるACKのみ（（snd.una -max.snd.wnd）<= seg.ack <= snd。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]）。この小さなチェックは、攻撃者が有効なシーケンス番号を推測する脆弱性を減らします。これは、ウィンドウ内シーケンス数を推測するだけでなく、スコープ範囲内の適切な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 << 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攻撃）を受け入れる際の堅牢性を改善するのにも役立ちます。とりわけ、この緩和では、攻撃者が接続の閉鎖につながるフィンセグメントを正常にスプーフィングするために、上記の範囲に承認番号を取得する必要があることも必要です。したがって、この緩和は、スプーフィングされたフィンセグメントに対する堅牢性を大幅に改善します。
Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.
上記の緩和は、非増幅ACK交換を引き起こす可能性があることに注意してください。この懸念はセクション10で説明されています。
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、およびデータの推奨レベルは、それぞれ必要な、および可能性のあるものと表示されます。データ緩和が一般的にTCPの堅牢性を増加させたとしても、データ緩和が可能な限りタグ付けされる理由は、データ注入がRSTおよびSynのカウンターパートと比較してより困難であると認識されている（2倍の可能性が高い）ためです。ただし、提案されたすべての緩和により、一般的にTCPの堅牢性が向上し、したがって、ドキュメントで推奨される一部またはすべての緩和を実装する選択が純粋に実装者に任されていることに注意する必要があります。
In order to alleviate multiple RSTs/SYNs from triggering multiple challenge ACKs, an ACK throttling mechanism is suggested as follows:
複数のRSTS/SYNを複数のチャレンジACKのトリガーから緩和するために、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.
これらの数値は本質的に経験的であり、いくつかの実装に存在する最初のスロットリングメカニズムから得られていることに注意する必要があります。また、上記のメカニズムを実装するためにタイマーは必要ないことに注意してください。代わりに、タイムスタンプとカウンターを使用できることに注意してください。
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.
帯域幅とCPUの使用率の保護にもっと懸念している管理者は、より少ないACKスロットル値を設定する可能性がありますが、古い接続のより速いクリーンアップに関心がある管理者（つまり、過剰なTCP状態を懸念する）は、より高い値を設定することを決定する可能性があります。任意の期間に処理されるより多くのRST。
The time limit SHOULD be tunable to help timeout brute force attacks faster than a potential legitimate flood of RSTs.
時間制限は、RSTの合法的な潜在的な洪水よりも速いブルートフォース攻撃をタイムアウトするのに役立つように調整可能でなければなりません。
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
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接続の両端が修正を必要とする必要があります。一方の端に緩和があると、その端が攻撃にさらされるのを防ぐことができますが、他方の端では依然として脆弱です。
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追跡接続を検討してください。E-Cがウィンドウ内にあるが接続をリセットする正確な一致ではないシーケンス番号を使用してRSTを送信し、M-Bがこのドキュメントで推奨される修正を持っていない場合、接続をクリアしてR-AをE-Aに転送して誤ったシーケンスを保存する可能性があります番号。E-Aに修正がない場合、必要に応じて接続がクリアされます。ただし、E-Aに必要な修正がある場合、e-cにチャレンジACKを送信します。ミドルボックスであるM-Bは、このACKをインターセプトし、古いシーケンス番号を使用してE-Cに代わってRSTを再送信する場合があります。このRは、繰り返しますが、受け入れられず、チャレンジ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.
M-BからE-Aまでの最初のシナリオが失われ、E-Aが接続を保持し続け、E-AがM-Bで接続状態が破壊された後、ACKを任意の時間に送信する可能性がある同様のシナリオを考えてみましょう。この場合、M-Bは、e-Aで接続がクリアされていることが確認されるまで、任意の時間を最初にキャッシュする必要があります。
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シーケンス番号を計算する場合があります。シナリオは以前のケースと同じですが、この場合、キャッシュされたRを送信する代わりに、Middlebox（M-B）は、ACK内の確認フィールドの合計としてシーケンス番号を計算する最初のRを送信します。以下に示すように、e-Aによって送信されたACK。以下のステップ1と2の間のシーケンス数の違いは、ネットワークで失われたデータによるものです。
TCP A Middlebox
TCP A Middlebox
1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED
1. 確立< - <seq = 500> <ack = 100> <ctl = rst> <-閉じている
2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
2. 確立 - > <seq = 100> <ack = 300> <wnd = 500> <ctl = ack> - >閉じている
3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
3. 確立< - <seq = 800> <ack = 100> <ctl = rst> <-閉じている
4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
4. 確立 - > <seq = 100> <ack = 300> <wnd = 500> <ctl = ack> - >閉じている
5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
5. 確立< - <seq = 800> <ack = 100> <ctl = rst> <-閉じている
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スロットリングメカニズムを実装することで軽減することができます。
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接続に関連するフロー状態をすでにクリアしていたために発生する可能性があります。このような場合、このドキュメントで説明されている最初の緩和を実装した最終ホストは、TCP接続を開いたままにします。これはコーナーケースであり、ミドルボックスがこのドキュメントで提案されている変更に適合している場合に消える可能性があります。
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]またはセキュリティペイロード（ESP）[RFC4303]をカプセル化するIPSECのいずれかを使用することです。
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は、Path攻撃者が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.
もう1つの注目すべき考慮事項は、必要なRST/SYN緩和手法でリフレクター攻撃が可能であることです。この攻撃では、オフパスの攻撃者が被害者に、被害者の現在の受信ウィンドウ内にあるスプーフィングされたRST/SYNセグメントごとにACKセグメントを送信する可能性があります。ただし、攻撃者が被害者が生成する各セグメントを生成しなければならないため、これは増幅を引き起こさないことに注意する必要があります。
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.
Cisco SystemsのMitesh DalalとAmol Khareは、RST/Syn攻撃のソリューションを考案しました。Cisco SystemsのAnantha RamaiahとRandall Stewartは、データインジェクションの脆弱性を発見し、Cisco SystemsのPatrick MahanとPeter Leiとともに、同じものがソリューションを見つけました。Paul Goyette、Mark Baushke、Frank Kastenholz、Art Stine、およびDavid Wang of Juniper Networksは、RSTとは別にSynsが手ごわい攻撃をもたらす可能性があるという洞察を提供しました。Cisco SystemsのShrirang Bage、Qing LiとWind River SystemsのPreety Puri、およびQNXソフトウェアのXiaodan Tangは、上記の人々とともに、提案されたソリューションの相互運用性の批准とテストに役立ちました。
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.
マーク・オールマン、テッド・フェイバー、スティーブ・ベロヴィン、ヴェルン・パクソン、アリソン・マンキン、シャラド・アラワット、ダミール・ラジノビッチ、ジョン・ウォン、ジョー・タッチ、アルフレッド・ホーエンズ、アンドレ・オプパーマン、フェルナンド・ゴント、サンドラ・マーフィー、ブライアン・カーペンター、クレン・ジェンニング、その他提案とコメントについては、TCPM WGのメンバー。ACKスロットリングは、TCPMワーキンググループの提案を組み合わせることにより、このドキュメントを紹介しました。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Medina、A.、Allman、M。、およびS. Floyd、「インターネットでの輸送プロトコルの進化の測定」、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] Braden、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] Jacobson、V.、Braden、B。、およびD. Borman、「TCP拡張のための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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953] Touch、J。、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[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>.
[SITW] Watson、P。、「ウィンドウのスリッピング：TCPリセット攻撃」、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] Larsen、M。およびF. Gont、「輸送プロトコルポートランダム化の推奨事項」、2010年8月の作業。
Authors' Addresses
著者のアドレス
Anantha Ramaiah Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
アナンサラマイアシスコシステム170タスマンドライブサンノゼ、カリフォルニア95134 USA
Phone: +1 (408) 525-6486
EMail: ananth@cisco.com
Randall R. Stewart Huawei 148 Crystal Cove Ct Chapin, SC 29036 USA
Randall R. Stewart Huawei 148 Crystal Cove CT Chapin、Sc 29036 USA
Phone: +1 (803) 345-0369
EMail: rstewart@huawei.com
Mitesh Dalal Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
Mitesh Dalal Cisco Systems 170 Tasman Drive San Jose、CA 95134 USA
Phone: +1 (408) 853-5257
EMail: mdalal@cisco.com