[要約] RFC 5927は、ICMP攻撃がTCPに対して行われる可能性を議論し、対策を提案するものです。その目的は、ネットワークセキュリティの向上と、TCPへの攻撃に対する防御策の普及です。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 5927 UTN/FRH
Category: Informational July 2010
ISSN: 2070-1721
ICMP Attacks against TCP
TCPに対するICMP攻撃
Abstract
概要
This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues.
このドキュメントでは、インターネット制御メッセージプロトコル（ICMP）を使用して、伝送制御プロトコル（TCP）に対してさまざまな攻撃を実行する方法について説明します。さらに、このドキュメントでは、これらの問題を軽減するのに役立つ、ICMPエラーメッセージのTCPの処理に広く実装されているいくつかの変更について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc5927.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5927で入手できます。
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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
2.1.1. ICMP for IP version 4 (ICMPv4) . . . . . . . . . . . . 5
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
2.2. Handling of ICMP Error Messages . . . . . . . . . . . . . 6
2.3. Handling of ICMP Error Messages in the Context of IPsec . 7
3. Constraints in the Possible Solutions . . . . . . . . . . . . 8
4. General Counter-Measures against ICMP Attacks . . . . . . . . 10
4.1. TCP Sequence Number Checking . . . . . . . . . . . . . . . 10
4.2. Port Randomization . . . . . . . . . . . . . . . . . . . . 11
4.3. Filtering ICMP Error Messages Based on the ICMP Payload . 11
5. Blind Connection-Reset Attack . . . . . . . . . . . . . . . . 12
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 13
6. Blind Throughput-Reduction Attack . . . . . . . . . . . . . . 16
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 16
7. Blind Performance-Degrading Attack . . . . . . . . . . . . . . 16
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 18
7.3. The Counter-Measure for the PMTUD Attack in Action . . . . 22
7.3.1. Normal Operation for Bulk Transfers . . . . . . . . . 22
7.3.2. Operation during Path-MTU Changes . . . . . . . . . . 24
7.3.3. Idle Connection Being Attacked . . . . . . . . . . . . 25
7.3.4. Active Connection Being Attacked after Discovery
of the Path-MTU . . . . . . . . . . . . . . . . . . . 26
7.3.5. TCP Peer Attacked when Sending Small Packets Just
after the Three-Way Handshake . . . . . . . . . . . . 26
7.4. Pseudo-Code for the Counter-Measure for the Blind
Performance-Degrading Attack . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 33
ICMP [RFC0792] [RFC4443] is a fundamental part of the TCP/IP protocol suite, and is used mainly for reporting network error conditions. However, the current specifications do not recommend any kind of validation checks on the received ICMP error messages, thus allowing a variety of attacks against TCP [RFC0793] by means of ICMP, which include blind connection-reset, blind throughput-reduction, and blind performance-degrading attacks. All of these attacks can be performed even when the attacker is off-path, without the need to sniff the packets that correspond to the attacked TCP connection.
ICMP [RFC0792] [RFC4443]は、TCP / IPプロトコルスイートの基本的な部分であり、主にネットワークエラー状態の報告に使用されます。ただし、現在の仕様では、受信したICMPエラーメッセージに対する検証チェックを推奨していないため、ICMPによるTCP [RFC0793]に対するさまざまな攻撃が可能です。これには、ブラインド接続リセット、ブラインドスループット削減、ブラインドが含まれます。パフォーマンス低下攻撃。これらの攻撃はすべて、攻撃者がパスから外れている場合でも実行できます。攻撃されたTCP接続に対応するパケットを盗聴する必要はありません。
While the possible security implications of ICMP have been known in the research community for a long time, there has never been an official proposal on how to deal with these vulnerabilities. In 2005, a disclosure process was carried out by the UK's National Infrastructure Security Co-ordination Centre (NISCC) (now CPNI, Centre for the Protection of National Infrastructure), with the collaboration of other computer emergency response teams. A large number of implementations were found vulnerable to either all or a subset of the attacks discussed in this document [NISCC][US-CERT]. The affected systems ranged from TCP/IP implementations meant for desktop computers, to TCP/IP implementations meant for core Internet routers.
ICMPのセキュリティへの影響の可能性は研究コミュニティで長い間知られていますが、これらの脆弱性に対処する方法に関する公式の提案はありません。 2005年に、他のコンピューター緊急対応チームの協力を得て、英国の国家インフラ安全保障調整センター（NISCC）（現在はCPNI、国家インフラ保護センター）によって開示プロセスが実施されました。このドキュメント[NISCC] [US-CERT]で説明されている攻撃のすべてまたは一部に対して脆弱な実装が多数見つかりました。影響を受けるシステムは、デスクトップコンピューター向けのTCP / IP実装から、コアインターネットルーター向けのTCP / IP実装まで多岐にわたりました。
It is clear that implementations should be more cautious when processing ICMP error messages, to eliminate or mitigate the use of ICMP to perform attacks against TCP [RFC4907].
ICMPエラーメッセージを処理する場合、TCPに対する攻撃を実行するためのICMPの使用を排除または軽減するために、実装がより慎重になる必要があることは明らかです[RFC4907]。
This document aims to raise awareness of the use of ICMP to perform a variety of attacks against TCP, and discusses several counter-measures that eliminate or minimize the impact of these attacks. Most of the these counter-measures can be implemented while still remaining compliant with the current specifications, as they simply describe reasons for not taking the advice provided in the specifications in terms of "SHOULDs", but still comply with the requirements stated as "MUSTs".
このドキュメントは、TCPに対するさまざまな攻撃を実行するためのICMPの使用の認識を高めることを目的とし、これらの攻撃の影響を排除または最小化するいくつかの対策について説明します。これらの対策のほとんどは、現在の仕様に準拠したまま実装することができます。これは、仕様で提供されたアドバイスを受け取らない理由を「SHOULD」の観点から説明しているだけであり、「MUST 」
We note that the counter-measures discussed in this document are not part of standard TCP behavior, and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard.
このドキュメントで説明されている対策は、標準のTCP動作の一部ではなく、このドキュメントはその状態を変更しないことに注意してください。 TCPM WG（TCP Maintenance and Minor Extensions Working Group）の合意は、非標準のTCP動作のこの広範囲にわたる実装を文書化することであり、TCP標準を変更しないことでした。
Section 2 provides background information on ICMP. Section 3 discusses the constraints in the general counter-measures that can be implemented against the attacks described in this document.
セクション2では、ICMPに関する背景情報を提供します。セクション3では、このドキュメントで説明する攻撃に対して実装できる一般的な対策の制約について説明します。
Section 4 describes several general validation checks that can be implemented to mitigate any ICMP-based attack. Finally, Section 5, Section 6, and Section 7, discuss a variety of ICMP attacks that can be performed against TCP, and describe attack-specific counter-measures that eliminate or greatly mitigate their impact.
セクション4では、ICMPベースの攻撃を軽減するために実装できるいくつかの一般的な検証チェックについて説明します。最後に、セクション5、セクション6、およびセクション7では、TCPに対して実行できるさまざまなICMP攻撃について説明し、その影響を排除または大幅に軽減する攻撃固有の対策について説明します。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The Internet Control Message Protocol (ICMP) is used in the Internet architecture mainly to perform the fault-isolation function, that is, the group of actions that hosts and routers take to determine that there is some network failure [RFC0816].
インターネット制御メッセージプロトコル（ICMP）は、主に障害分離機能、つまりネットワーク障害があることを確認するためにホストとルーターが実行する一連のアクション[RFC0816]を実行するためにインターネットアーキテクチャで使用されます。
When an intermediate router detects a network problem while trying to forward an IP packet, it will usually send an ICMP error message to the source system, to inform the source system of the network problem taking place. In the same way, there are a number of scenarios in which an end-system may generate an ICMP error message if it finds a problem while processing a datagram. The received ICMP errors are handed to the corresponding transport-protocol instance, which will usually perform a fault recovery function.
中間ルーターがIPパケットを転送しようとしているときにネットワークの問題を検出すると、通常はソースシステムにICMPエラーメッセージを送信して、ネットワークの問題が発生していることをソースシステムに通知します。同様に、エンドシステムがデータグラムの処理中に問題を検出した場合に、ICMPエラーメッセージを生成するシナリオがいくつかあります。受信したICMPエラーは、対応するトランスポートプロトコルインスタンスに渡されます。インスタンスは通常、障害回復機能を実行します。
It is important to note that ICMP error messages are transmitted unreliably and may be discarded due to data corruption, network congestion, or rate-limiting. Thus, while they provide useful information, upper-layer protocols cannot depend on ICMP for correct operation.
ICMPエラーメッセージは確実に送信されず、データの破損、ネットワークの輻輳、またはレート制限が原因で破棄される場合があることに注意することが重要です。したがって、それらは有用な情報を提供しますが、上位層プロトコルは、正しい動作をICMPに依存できません。
It should be noted that there are no timeliness requirements for ICMP error messages. ICMP error messages could be delayed for various reasons, and at least in theory could be received with an arbitrarily long delay. For example, there are no existing requirements that a router flush any queued ICMP error messages when it is rebooted.
ICMPエラーメッセージの適時性要件はないことに注意してください。 ICMPエラーメッセージはさまざまな理由で遅延する可能性があり、少なくとも理論的には任意の長い遅延で受信される可能性があります。たとえば、再起動時にルーターがキューにあるICMPエラーメッセージをフラッシュするという既存の要件はありません。
[RFC0792] specifies the Internet Control Message Protocol (ICMP) to be used with the Internet Protocol version 4 (IPv4) -- henceforth "ICMPv4". It defines, among other things, a number of error messages that can be used by end-systems and intermediate systems to report errors to the sending system. The Host Requirements RFC [RFC1122] classifies ICMPv4 error messages into those that indicate "soft errors", and those that indicate "hard errors", thus roughly defining the semantics of them.
[RFC0792]は、インターネット制御メッセージプロトコル（ICMP）をインターネットプロトコルバージョン4（IPv4）で使用するように指定します。とりわけ、エンドシステムと中間システムがエラーを送信側システムに報告するために使用できるいくつかのエラーメッセージを定義します。ホスト要件RFC [RFC1122]は、ICMPv4エラーメッセージを「ソフトエラー」を示すものと「ハードエラー」を示すものに分類し、その意味を大まかに定義します。
The ICMPv4 specification [RFC0792] also defines the ICMPv4 Source Quench message (type 4, code 0), which is meant to provide a mechanism for flow control and congestion control.
ICMPv4仕様[RFC0792]では、ICMPv4 Source Quenchメッセージ（タイプ4、コード0）も定義されています。これは、フロー制御と輻輳制御のメカニズムを提供することを目的としています。
[RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), which makes use of ICMPv4 error messages of type 3 (Destination Unreachable), code 4 (fragmentation needed and DF bit set) to allow systems to determine the MTU of an arbitrary internet path.
[RFC1191]は、「パスMTUディスカバリー」（PMTUD）と呼ばれるメカニズムを定義しています。これは、タイプ3（宛先到達不能）、コード4（フラグメンテーションが必要、DFビットセット）のICMPv4エラーメッセージを利用して、システムが任意のインターネットパス。
Finally, [RFC4884] redefines selected ICMPv4 messages to include an extension structure and a length attribute, such that those ICMPv4 messages can carry additional information by encoding that information in the extension structure.
最後に、[RFC4884]は、選択されたICMPv4メッセージを再定義し、拡張構造と長さ属性を含めて、それらのICMPv4メッセージが追加情報を運ぶことができるように、その情報を拡張構造にエンコードします。
Appendix D of [RFC4301] provides information about which ICMPv4 error messages are produced by hosts, intermediate routers, or both.
[RFC4301]の付録Dは、ホスト、中間ルーター、またはその両方によって生成されるICMPv4エラーメッセージに関する情報を提供します。
[RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to be used with the Internet Protocol version 6 (IPv6) [RFC2460].
[RFC4443]は、インターネットプロトコルバージョン6（IPv6）[RFC2460]で使用されるインターネット制御メッセージプロトコル（ICMPv6）を指定します。
[RFC4443] defines the "Packet Too Big" (type 2, code 0) error message, which is analogous to the ICMPv4 "fragmentation needed and DF bit set" (type 3, code 4) error message. [RFC1981] defines the Path MTU Discovery mechanism for IP version 6, which makes use of these messages to determine the MTU of an arbitrary internet path.
[RFC4443]は、 "Packet Too Big"（タイプ2、コード0）エラーメッセージを定義します。これは、ICMPv4 "フラグメンテーションが必要で、DFビットセット"（タイプ3、コード4）エラーメッセージに類似しています。 [RFC1981]は、IPバージョン6のパスMTU検出メカニズムを定義しています。これは、これらのメッセージを利用して任意のインターネットパスのMTUを決定します。
Finally, [RFC4884] redefines selected ICMPv6 messages to include an extension structure and a length attribute, such that those ICMPv6 messages can carry additional information by encoding that information in the extension structure.
最後に、[RFC4884]は、選択されたICMPv6メッセージを再定義して、拡張構造と長さ属性を含めます。これにより、これらのICMPv6メッセージは、拡張構造で情報をエンコードすることによって追加情報を運ぶことができます。
Appendix D of [RFC4301] provides information about which ICMPv6 error messages are produced by hosts, intermediate routers, or both.
[RFC4301]の付録Dは、ホスト、中間ルーター、またはその両方によって生成されるICMPv6エラーメッセージに関する情報を提供します。
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that TCP MUST act on an ICMP error message passed up from the IP layer, directing it to the connection that triggered the error.
ホスト要件RFC [RFC1122]はセクション4.2.3.9で、TCPはIP層から渡されたICMPエラーメッセージに基づいて動作し、エラーをトリガーした接続に送信する必要があると述べています。
In order to allow ICMP messages to be demultiplexed by the receiving system, part of the original packet that triggered the message is included in the payload of the ICMP error message. Thus, the receiving system can use that information to match the ICMP error to the transport protocol instance that triggered it.
ICMPメッセージを受信システムで逆多重化できるようにするために、メッセージをトリガーした元のパケットの一部がICMPエラーメッセージのペイロードに含まれています。したがって、受信システムはその情報を使用して、ICMPエラーを、それをトリガーしたトランスポートプロトコルインスタンスと照合できます。
Neither the Host Requirements RFC [RFC1122] nor the original TCP specification [RFC0793] recommends any validation checks on the received ICMP messages. Thus, as long as the ICMP payload contains the information that identifies an existing communication instance, it will be processed by the corresponding transport-protocol instance, and the corresponding action will be performed.
ホスト要件RFC [RFC1122]も元のTCP仕様[RFC0793]も、受信したICMPメッセージの検証チェックを推奨していません。したがって、ICMPペイロードに既存の通信インスタンスを識別する情報が含まれている限り、それは対応するトランスポートプロトコルインスタンスによって処理され、対応するアクションが実行されます。
Therefore, in the case of TCP, an attacker could send a crafted ICMP error message to the attacked system, and, as long as he is able to guess the four-tuple (i.e., Source IP Address, Source TCP port, Destination IP Address, and Destination TCP port) that identifies the communication instance to be attacked, he will be able to use ICMP to perform a variety of attacks.
したがって、TCPの場合、攻撃者は巧妙に細工されたICMPエラーメッセージを攻撃されたシステムに送信し、4つのタプル（つまり、送信元IPアドレス、送信元TCPポート、宛先IPアドレス）を推測できる限り、 、および攻撃対象の通信インスタンスを識別する宛先TCPポート）、ICMPを使用してさまざまな攻撃を実行できるようになります。
Generally, the four-tuple required to perform these attacks is not known. However, as discussed in [Watson] and [RFC4953], there are a number of scenarios (notably that of TCP connections established between two BGP routers [RFC4271]) in which an attacker may be able to know or guess the four-tuple that identifies a TCP connection. In such a case, if we assume the attacker knows the two systems involved in the TCP connection to be attacked, both the client-side and the server-side IP addresses could be known or be within a reasonable number of possibilities. Furthermore, as most Internet services use the so-called "well-known" ports, only the client port number might need to be guessed. In such a scenario, an attacker would need to send, in principle, at most 65536 packets to perform any of the attacks described in this document. These issues are exacerbated by the fact that most systems choose the port numbers they use for outgoing connections from a subset of the whole port number space, thus reducing the amount of work needed to successfully perform these attacks.
一般に、これらの攻撃を実行するために必要な4タプルは不明です。ただし、[ワトソン]と[RFC4953]で説明されているように、攻撃者が4つのタプルを知ったり推測したりできるシナリオがいくつかあります（特に2つのBGPルーター[RFC4271]間に確立されたTCP接続のシナリオ）。 TCP接続を識別します。このような場合、攻撃者が攻撃対象のTCP接続に関与する2つのシステムを知っていると想定すると、クライアント側とサーバー側の両方のIPアドレスが既知であるか、妥当な数の可能性の範囲内にある可能性があります。さらに、ほとんどのインターネットサービスはいわゆる「既知の」ポートを使用するため、クライアントのポート番号のみを推測する必要がある場合があります。このようなシナリオでは、攻撃者はこのドキュメントで説明されている攻撃を実行するために、原則として最大65536パケットを送信する必要があります。これらの問題は、ほとんどのシステムが発信接続に使用するポート番号をポート番号空間全体のサブセットから選択するため、これらの攻撃を成功させるために必要な作業量が減少するため、悪化します。
The need to be more cautious when processing received ICMP error messages in order to mitigate or eliminate the impact of the attacks described in this RFC has been documented by the Internet Architecture Board (IAB) in [RFC4907].
このRFCで説明されている攻撃の影響を緩和または排除するために、受信したICMPエラーメッセージを処理する際により注意する必要があることは、インターネットアーキテクチャボード（IAB）の[RFC4907]で文書化されています。
Section 5.2 of [RFC4301] describes the processing of inbound IP traffic in the case of "unprotected-to-protected". In the case of ICMP, when an unprotected ICMP error message is received, it is matched to the corresponding security association by means of the SPI (Security Parameters Index) included in the payload of the ICMP error message. Then, local policy is applied to determine whether to accept or reject the message and, if accepted, what action to take as a result. For example, if an ICMP Destination Unreachable message is received, the implementation must decide whether to act on it, reject it, or act on it with constraints. Section 8 ("Path MTU/DF Processing") discusses the processing of unauthenticated ICMPv4 "fragmentation needed and DF bit set" (type 3, code 4) and ICMPv6 "Packet Too Big" (type 2, code 0) messages when an IPsec implementation is configured to process (vs. ignore) such messages.
[RFC4301]のセクション5.2では、「保護されていない」から「保護されている」場合の受信IPトラフィックの処理について説明しています。 ICMPの場合、保護されていないICMPエラーメッセージが受信されると、ICMPエラーメッセージのペイロードに含まれるSPI（セキュリティパラメータインデックス）によって、対応するセキュリティアソシエーションと照合されます。次に、ローカルポリシーを適用して、メッセージを受け入れるか拒否するかを決定し、受け入れられた場合に結果として実行するアクションを決定します。たとえば、ICMP Destination Unreachableメッセージが受信された場合、実装はそれに対処するか、拒否するか、または制約付きで対処するかを決定する必要があります。セクション8（「パスMTU / DF処理」）では、認証されていないICMPv4「フラグメンテーションが必要であり、DFビットセット」（タイプ3、コード4）およびICMPv6「パケットが大きすぎます」（タイプ2、コード0）メッセージのIPsec時の処理について説明します。実装は、このようなメッセージを処理する（無視する）ように構成されています。
Section 6.1.1 of [RFC4301] notes that processing of unauthenticated ICMP error messages may result in denial or degradation of service, and therefore it would be desirable to ignore such messages. However, it also notes that in many cases, ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTUD and redirection messages, and therefore there is also a motivation for accepting and acting upon them. It finally states that to accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic, and that this control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic.
[RFC4301]のセクション6.1.1は、認証されていないICMPエラーメッセージの処理がサービスの拒否または低下を引き起こす可能性があるため、そのようなメッセージを無視することが望ましいと述べています。ただし、多くの場合、これらのICMPメッセージを無視すると、たとえばPMTUDとリダイレクトメッセージの処理に失敗したためにサービスが低下する可能性があるため、それらを受け入れて対処する動機もあることに注意してください。最後に、このスペクトラムの両端に対応するために、準拠したIPsec実装は、ローカル管理者が認証されていないICMPトラフィックを受け入れるか拒否するようにIPsec実装を構成することを許可しなければならず、この制御はICMPタイプの粒度である必要があり、 ICMPタイプとコードの粒度。さらに、実装には、そのようなトラフィックを処理するためのメカニズムとパラメータを組み込む必要があります（SHOULD）。
Thus, the policy to apply for the processing of unprotected ICMP error messages is left up to the implementation and administrator.
したがって、保護されていないICMPエラーメッセージの処理に適用するポリシーは、実装と管理者に委ねられています。
If a host wants to perform validation checks on the received ICMP error messages before acting on them, it is limited by the piece of the packet that triggered the error that the sender of the ICMP error message chose to include in the ICMP payload. This constrains the possible validation checks, as the number of bytes of the packet that triggered the error message that is included in the ICMP payload is limited.
ホストが受信したICMPエラーメッセージを検証する前に検証チェックを実行する場合、ICMPエラーメッセージの送信者がICMPペイロードに含めることを選択したエラーをトリガーしたパケットの一部によって制限されます。これにより、ICMPペイロードに含まれるエラーメッセージをトリガーしたパケットのバイト数が制限されるため、可能な検証チェックが制限されます。
For ICMPv4, [RFC0792] states that the IP header plus the first 64 bits of the packet that triggered the ICMPv4 message are to be included in the payload of the ICMPv4 error message. Thus, it is assumed that all data needed to identify a transport protocol instance and process the ICMPv4 error message is contained in the first 64 bits of the transport protocol header. Section 3.2.2 of [RFC1122] states that "the Internet header and at least the first 8 data octets of the datagram that triggered the error" are to be included in the payload of ICMPv4 error messages, and that "more than 8 octets MAY be sent", thus allowing implementations to include more data from the original packet than those required by the original ICMPv4 specification. The "Requirements for IP Version 4 Routers" RFC [RFC1812] states that ICMPv4 error messages "SHOULD contain as much of the original datagram as possible without the length of the ICMP datagram exceeding 576 bytes".
ICMPv4の場合、[RFC0792]には、IPヘッダーと、ICMPv4メッセージをトリガーしたパケットの最初の64ビットがICMPv4エラーメッセージのペイロードに含まれることが記載されています。したがって、トランスポートプロトコルインスタンスを識別してICMPv4エラーメッセージを処理するために必要なすべてのデータは、トランスポートプロトコルヘッダーの最初の64ビットに含まれていると想定されます。 [RFC1122]のセクション3.2.2では、「インターネットヘッダーと、エラーをトリガーしたデータグラムの少なくとも最初の8データオクテット」をICMPv4エラーメッセージのペイロードに含めること、および「8オクテット以上これにより、元のICMPv4仕様で必要なデータよりも多くのデータを元のパケットに含めることができます。 「IPバージョン4ルーターの要件」RFC [RFC1812]には、ICMPv4エラーメッセージに「ICMPデータグラムの長さが576バイトを超えないように、できるだけ多くの元のデータグラムを含める必要がある」と記載されています。
Thus, for ICMPv4 messages generated by hosts, we can only expect to get the entire IP header of the original packet, plus the first 64 bits of its payload. For TCP, this means that the only fields that will be included in the ICMPv4 payload are the source port number, the destination port number, and the 32-bit TCP sequence number. This clearly imposes a constraint on the possible validation checks that can be performed, as there is not much information available on which to perform them.
したがって、ホストによって生成されたICMPv4メッセージの場合、元のパケットのIPヘッダー全体と、そのペイロードの最初の64ビットのみを取得することを期待できます。 TCPの場合、これはICMPv4ペイロードに含まれる唯一のフィールドが送信元ポート番号、宛先ポート番号、および32ビットTCPシーケンス番号であることを意味します。これにより、実行できる検証チェックに制約が課せられます。検証を実行するために利用できる情報があまりないためです。
This means, for example, that even if TCP were signing its segments by means of the TCP MD5 signature option [RFC2385], this mechanism could not be used as a counter-measure against ICMP-based attacks, because, as ICMP messages include only a piece of the TCP segment that triggered the error, the MD5 [RFC1321] signature could not be recalculated. In the same way, even if the attacked peer were authenticating its packets at the IP layer [RFC4301], because only a part of the original IP packet would be available, the signature used for authentication could not be recalculated, and thus the authentication header in the original packet could not be used as a counter-measure for ICMP-based attacks against TCP.
これは、たとえば、TCPがTCP MD5署名オプション[RFC2385]を使用してセグメントに署名していたとしても、ICMPメッセージには次のものだけが含まれているため、このメカニズムをICMPベースの攻撃への対策として使用できないことを意味します。エラーを引き起こしたTCPセグメントの一部であるMD5 [RFC1321]シグネチャを再計算できませんでした。同様に、攻撃されたピアがIPレイヤーでパケットを認証していたとしても[RFC4301]、元のIPパケットの一部しか利用できないため、認証に使用される署名を再計算できず、認証ヘッダーが元のパケットでは、TCPに対するICMPベースの攻撃の対策として使用できませんでした。
[RFC4884] updated [RFC0792] and specified that ICMPv4 Destination Unreachable (type 3), Time Exceeded (type 11), and Parameter Problem (type 12) messages that have an ICMP Extension Structure appended include at least 128 octets in the "original datagram" field. This would improve the situation, but at the time of this writing, [RFC4884] is not yet widely deployed for end-systems.
[RFC4884]は[RFC0792]を更新し、ICMPv4 Destination Unreachable（type 3）、Time Exceeded（type 11）、およびParameter Problem（type 12）のメッセージにICMP拡張構造が追加されていると、「元のデータグラムに少なくとも128オクテットが含まれるように指定しました。 "フィールド。これは状況を改善しますが、この記事の執筆時点では、[RFC4884]はまだエンドシステムに広く展開されていません。
For IPv6, the payload of ICMPv6 error messages includes as many octets from the IPv6 packet that triggered the ICMPv6 error message as will fit without making the resulting ICMPv6 error message exceed the minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information is available than in the IPv4 case.
IPv6の場合、ICMPv6エラーメッセージのペイロードには、ICMPv6エラーメッセージをトリガーしたIPv6パケットからのオクテットが、結果のICMPv6エラーメッセージが最小IPv6 MTU（1280オクテット）[RFC4443]を超えることなく収まるだけ含まれます。したがって、IPv4の場合よりも多くの情報を利用できます。
Hosts could require ICMP error messages to be authenticated [RFC4301], in order to act upon them. However, while this requirement could make sense for those ICMP error messages sent by hosts, it would not be feasible for those ICMP error messages generated by routers, as this would imply either that the attacked system should have a security association [RFC4301] with every existing intermediate system, or that it should be able to establish one dynamically. Current levels of deployment of protocols for dynamic establishment of security associations makes this unfeasible. Additionally, this would require routers to use certificates with paths compatible for all hosts on the network. Finally, there may be some scenarios, such as embedded devices, in which the processing power requirements of authentication might not allow IPsec authentication to be implemented effectively.
ホストは、ホストに作用するために、ICMPエラーメッセージの認証[RFC4301]を要求する可能性があります。ただし、この要件はホストによって送信されたICMPエラーメッセージには意味がありますが、攻撃されたシステムにはすべてのセキュリティアソシエーション[RFC4301]が必要であることを意味するため、ルーターによって生成されたICMPエラーメッセージには適していません。既存の中間システム、または動的にシステムを確立できる必要があります。セキュリティアソシエーションの動的な確立のためのプロトコルの展開の現在のレベルでは、これを実行できません。さらに、ルーターはネットワーク上のすべてのホストと互換性のあるパスを持つ証明書を使用する必要があります。最後に、組み込みデバイスなど、認証の処理能力要件によってIPsec認証を効果的に実装できないシナリオがいくつかあります。
The following subsections describe a number of mitigation techniques that help to eliminate or mitigate the impact of the attacks discussed in this document. Rather than being alternative counter-measures, they can be implemented together to increase the protection against these attacks.
次のサブセクションでは、このドキュメントで説明する攻撃の影響を排除または軽減するのに役立ついくつかの軽減技術について説明します。代替の対策ではなく、これらを一緒に実装して、これらの攻撃に対する保護を強化できます。
The current specifications do not impose any validity checks on the TCP segment that is contained in the ICMP payload. For instance, no checks are performed to verify that a received ICMP error message has been triggered by a segment that was "in flight" to the destination. Thus, even stale ICMP error messages will be acted upon.
現在の仕様では、ICMPペイロードに含まれているTCPセグメントに有効性チェックは課されていません。たとえば、受信したICMPエラーメッセージが宛先に「飛行中」のセグメントによってトリガーされたことを確認するチェックは実行されません。したがって、古いICMPエラーメッセージでも処理されます。
Many TCP implementations have incorporated a validation check such that they react only to those ICMP error messages that appear to relate to segments currently "in flight" to the destination system. These implementations check that the TCP sequence number contained in the payload of the ICMP error message is within the range SND.UNA =< SEG.SEQ < SND.NXT. This means that they require that the sequence number be within the range of the data already sent but not yet acknowledged. If an ICMP error message does not pass this check, it is discarded.
多くのTCP実装は、現在宛先システムに「進行中」のセグメントに関連していると思われるICMPエラーメッセージにのみ反応するように、検証チェックを組み込んでいます。これらの実装は、ICMPエラーメッセージのペイロードに含まれるTCPシーケンス番号がSND.UNA = <SEG.SEQ <SND.NXTの範囲内であることを確認します。これは、シーケンス番号がすでに送信されたがまだ確認されていないデータの範囲内にある必要があることを意味します。 ICMPエラーメッセージがこのチェックに合格しない場合は、破棄されます。
Even if an attacker were able to guess the four-tuple that identifies the TCP connection, this additional check would reduce the possibility of considering a spoofed ICMP packet as valid to Flight_Size/2^^32 (where Flight_Size is the number of data bytes already sent to the remote peer, but not yet acknowledged [RFC5681]). For connections in the SYN-SENT or SYN-RECEIVED states, this would reduce the possibility of considering a spoofed ICMP packet as valid to 1/2^^32. For a TCP endpoint with no data "in flight", this would completely eliminate the possibility of success of these attacks.
攻撃者がTCP接続を識別する4タプルを推測できたとしても、この追加のチェックにより、スプーフィングされたICMPパケットが有効であるとFlight_Size / 2 ^^ 32と見なす可能性が減少します（Flight_Sizeは既にデータバイト数です）リモートピアに送信されましたが、まだ確認されていません[RFC5681]）。 SYN-SENTまたはSYN-RECEIVED状態の接続の場合、これにより、スプーフィングされたICMPパケットが有効であると見なされる可能性が1/2 ^^ 32に減少します。 「処理中」のデータがないTCPエンドポイントの場合、これによりこれらの攻撃が成功する可能性は完全に排除されます。
This validation check has been implemented in Linux [Linux] for many years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and NetBSD [NetBSD] since 2005.
この検証チェックは、Linux [Linux]、2004年以降のOpenBSD [OpenBSD]、2005年以降のFreeBSD [FreeBSD]およびNetBSD [NetBSD]に実装されています。
It is important to note that while this check greatly increases the number of packets required to perform any of the attacks discussed in this document, this may not be enough in those scenarios in which bandwidth is easily available and/or large TCP windows [RFC1323] are in use. Additionally, this validation check does not help to prevent on-path attacks, that is, attacks performed in scenarios in which the attacker can sniff the packets that correspond to the target TCP connection.
このチェックにより、このドキュメントで説明されている攻撃を実行するために必要なパケット数が大幅に増加しますが、帯域幅が簡単に利用できるシナリオや大きなTCPウィンドウ[RFC1323]では不十分な場合があることに注意してください。使用中です。さらに、この検証チェックは、パス上の攻撃、つまり、攻撃者がターゲットTCP接続に対応するパケットを盗聴できるシナリオで実行される攻撃の防止には役立ちません。
It should be noted that, as there are no timeliness requirements for ICMP error messages, the TCP Sequence Number check described in this section might cause legitimate ICMP error messages to be discarded. Also, even if this check is enforced, TCP might end up responding to stale ICMP error messages (e.g., if the Sequence Number for the corresponding direction of the data transfer wraps around).
ICMPエラーメッセージには適時性要件がないため、このセクションで説明するTCPシーケンス番号チェックにより、正当なICMPエラーメッセージが破棄される可能性があることに注意してください。また、このチェックが実施されていても、TCPは古いICMPエラーメッセージに応答してしまう可能性があります（たとえば、データ転送の対応する方向のシーケンス番号が循環する場合）。
As discussed in the previous sections, in order to perform any of the attacks described in this document, an attacker would need to guess (or know) the four-tuple that identifies the connection to be attacked. Increasing the port number range used for outgoing TCP connections, and randomizing the port number chosen for each outgoing TCP connection, would make it harder for an attacker to perform any of the attacks discussed in this document.
前のセクションで説明したように、このドキュメントで説明する攻撃を実行するには、攻撃者は攻撃対象の接続を識別する4つのタプルを推測（または知っている）する必要があります。発信TCP接続に使用するポート番号の範囲を増やし、発信TCP接続ごとに選択したポート番号をランダム化すると、攻撃者がこのドキュメントで説明する攻撃を実行することが困難になります。
[PORT-RANDOM] recommends that transport protocols randomize the ephemeral ports used by clients, and proposes a number of randomization algorithms.
[PORT-RANDOM]は、トランスポートプロトコルがクライアントによって使用される一時的なポートをランダム化することを推奨し、いくつかのランダム化アルゴリズムを提案します。
The source address of ICMP error messages does not need to be spoofed to perform the attacks described in this document, as the ICMP error messages might legitimately come from an intermediate system. Therefore, simple filtering based on the source address of ICMP error messages does not serve as a counter-measure against these attacks. However, a more advanced packet filtering can be implemented in middlebox devices such as firewalls and NATs. Middleboxes implementing such advanced filtering look at the payload of the ICMP error messages, and perform ingress and egress packet filtering based on the source address of the IP header contained in the payload of the ICMP error message. As the source address contained in the payload of the ICMP error message does need to be spoofed to perform the attacks described in this document, this kind of advanced filtering serves as a counter-measure against these attacks. As with traditional egress filtering [IP-filtering], egress filtering based on the ICMP payload can help to prevent users of the network being protected by the firewall from successfully performing ICMP attacks against TCP connections established between external systems. Additionally, ingress filtering based on the ICMP payload can prevent TCP connections established between internal systems from being attacked by external systems. [ICMP-Filtering] provides examples of ICMP filtering based on the ICMP payload.
ICMPエラーメッセージは中間システムから合法的に送信される可能性があるため、このドキュメントで説明されている攻撃を実行するために、ICMPエラーメッセージの送信元アドレスを偽装する必要はありません。したがって、ICMPエラーメッセージの送信元アドレスに基づく単純なフィルタリングは、これらの攻撃に対する対策として機能しません。ただし、ファイアウォールやNATなどのミドルボックスデバイスには、より高度なパケットフィルタリングを実装できます。このような高度なフィルタリングを実装するミドルボックスは、ICMPエラーメッセージのペイロードを確認し、ICMPエラーメッセージのペイロードに含まれるIPヘッダーの送信元アドレスに基づいて、入出力パケットフィルタリングを実行します。このドキュメントで説明する攻撃を実行するには、ICMPエラーメッセージのペイロードに含まれる送信元アドレスを偽装する必要があるため、この種の高度なフィルタリングは、これらの攻撃に対する対策として機能します。従来の出力フィルタリング[IPフィルタリング]と同様に、ICMPペイロードに基づく出力フィルタリングは、ファイアウォールによって保護されているネットワークのユーザーが、外部システム間に確立されたTCP接続に対してICMP攻撃を正常に実行できないようにするのに役立ちます。さらに、ICMPペイロードに基づく入力フィルタリングにより、内部システム間で確立されたTCP接続が外部システムによって攻撃されるのを防ぐことができます。 [ICMP-Filtering]は、ICMPペイロードに基づくICMPフィルタリングの例を提供します。
This filtering technique has been implemented in OpenBSD's Packet Filter [OpenBSD-PF], which has in turn been ported to a number of systems, including FreeBSD [FreeBSD].
このフィルタリング技術は、OpenBSDのパケットフィルター[OpenBSD-PF]に実装されており、FreeBSD [FreeBSD]を含む多くのシステムに移植されています。
When TCP is handed an ICMP error message, it will perform its fault recovery function, as follows:
TCPにICMPエラーメッセージが渡されると、TCPは次のように障害回復機能を実行します。
o If the network problem being reported is a "hard error", TCP will abort the corresponding connection.
o 報告されているネットワークの問題が「ハードエラー」の場合、TCPは対応する接続を中止します。
o If the network problem being reported is a "soft error", TCP will just record this information, and repeatedly retransmit its data until they either get acknowledged, or the connection times out.
o 報告されているネットワークの問題が「ソフトエラー」の場合、TCPはこの情報を記録し、確認されるか、接続がタイムアウトするまで、データを繰り返し再送信します。
The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that a host SHOULD abort the corresponding connection when receiving an ICMPv4 error message that indicates a "hard error", and states that ICMPv4 error messages of type 3 (Destination Unreachable), codes 2 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation needed and DF bit set) should be considered as indicating "hard errors". In the case of ICMPv4 port unreachables, the specifications are ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD abort the corresponding connection in response to them, but Section 3.2.2.1 of the same RFC ([RFC1122]) states that TCP MUST abort the connection in response to them.
ホスト要件RFC [RFC1122]では、「ハードエラー」を示すICMPv4エラーメッセージを受信すると、ホストは対応する接続を中止する必要がある（4.2.3.9項）と述べており、タイプ3（宛先到達不能）のICMPv4エラーメッセージは、コード2（プロトコル到達不能）、3（ポート到達不能）、および4（フラグメンテーションが必要で、DFビットセット）は、「ハードエラー」を示すと見なされます。 ICMPv4ポート到達不能の場合、[RFC1122]のセクション4.2.3.9は対応する接続をTCP SHOULDで切断する必要があるが、同じRFC（[RFC1122]）のセクション3.2.2.1が示すように、仕様はあいまいです。そのTCPは、それらに応答して接続を中止する必要があります。
While [RFC4443] did not exist when [RFC1122] was published, one could extrapolate the concept of "hard errors" to ICMPv6 error messages of type 1 (Destination Unreachable), codes 1 (communication with destination administratively prohibited), and 4 (port unreachable).
[RFC1122]の公開時には[RFC4443]は存在しませんでしたが、「ハードエラー」の概念をタイプ1（宛先到達不能）、コード1（宛先との通信は管理上禁止）、および4（ポート）のICMPv6エラーメッセージに外挿できます到達不能）。
Thus, an attacker could use ICMP to perform a blind connection-reset attack by sending any ICMP error message that indicates a "hard error" to either of the two TCP endpoints of the connection. Because of TCP's fault recovery policy, the connection would be immediately aborted.
したがって、攻撃者はICMPを使用して、接続の2つのTCPエンドポイントのいずれかに「ハードエラー」を示すICMPエラーメッセージを送信することにより、ブラインド接続リセット攻撃を実行する可能性があります。 TCPの障害回復ポリシーにより、接続はすぐに中止されます。
Some stacks are known to extrapolate ICMP "hard errors" across TCP connections, increasing the impact of this attack, as a single ICMP packet could bring down all the TCP connections between the corresponding peers.
単一のICMPパケットが対応するピア間のすべてのTCP接続をダウンさせる可能性があるため、一部のスタックはTCP接続全体でICMP「ハードエラー」を推定し、この攻撃の影響を増大させることが知られています。
It is important to note that even if TCP itself were protected against the blind connection-reset attack described in [Watson] and [TCPM-TCPSECURE] by means of authentication at the network layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], by means of the TCP-AO [RFC5925], or by means of the mechanism specified in [TCPM-TCPSECURE], the blind connection-reset attack described in this document would still succeed.
[Watson]および[TCPM-TCPSECURE]で説明されているブラインド接続リセット攻撃からTCP自体がネットワーク層[RFC4301]での認証によって、TCP MD5署名オプションによって保護されている場合でも、注意することが重要です。 [RFC2385]、TCP-AO [RFC5925]、または[TCPM-TCPSECURE]で指定されたメカニズムにより、このドキュメントで説明されているブラインド接続リセット攻撃は引き続き成功します。
An analysis of the circumstances in which ICMP messages that indicate "hard errors" may be received can shed some light on opportunities to mitigate the impact of ICMP-based blind connection-reset attacks.
「ハードエラー」を示すICMPメッセージが受信される可能性がある状況を分析すると、ICMPベースのブラインド接続リセット攻撃の影響を軽減する機会が明らかになります。
ICMPv4 type 3 (Destination Unreachable), code 2 (protocol unreachable)
ICMPv4タイプ3（宛先到達不能）、コード2（プロトコル到達不能）
This ICMP error message indicates that the host sending the ICMP error message received a packet meant for a transport protocol it does not support. For connection-oriented protocols such as TCP, one could expect to receive such an error as the result of a connection-establishment attempt. However, it would be strange to get such an error during the life of a connection, as this would indicate that support for that transport protocol has been removed from the system sending the error message during the life of the corresponding connection.
このICMPエラーメッセージは、ICMPエラーメッセージを送信するホストが、サポートしていないトランスポートプロトコル用のパケットを受信したことを示しています。 TCPなどのコネクション型プロトコルの場合、接続確立の試行の結果としてこのようなエラーを受け取ることが予想されます。ただし、対応する接続の存続中にエラーメッセージを送信しているシステムからそのトランスポートプロトコルのサポートが削除されたことを示しているため、接続の存続中にこのようなエラーが発生するのは奇妙です。
ICMPv4 type 3 (Destination Unreachable), code 3 (port unreachable)
ICMPv4タイプ3（宛先到達不能）、コード3（ポート到達不能）
This error message indicates that the system sending the ICMP error message received a packet meant for a socket (IP address, port number) on which there is no process listening. Those transport protocols that have their own mechanisms for signaling this condition should not be receiving these error messages, as the protocol would signal the port unreachable condition by means of its own mechanisms. Assuming that once a connection is established it is not usual for the transport protocol to change (or be reloaded), it should be unusual to get these error messages.
このエラーメッセージは、ICMPエラーメッセージを送信するシステムが、プロセスがリッスンしていないソケット（IPアドレス、ポート番号）用のパケットを受信したことを示します。この状態を通知する独自のメカニズムを備えたトランスポートプロトコルは、独自のメカニズムによってポート到達不能状態を通知するため、これらのエラーメッセージを受信してはなりません。いったん接続が確立されると、トランスポートプロトコルが変更（またはリロード）されるのが通常ではないと想定すると、これらのエラーメッセージが表示されることは珍しいはずです。
ICMPv4 type 3 (Destination Unreachable), code 4 (fragmentation needed and DF bit set) This error message indicates that an intermediate node needed to fragment a datagram, but the DF (Don't Fragment) bit in the IP header was set. It is considered a "soft error" when TCP implements PMTUD, and a "hard error" if TCP does not implement PMTUD. Those TCP/IP stacks that do not implement PMTUD (or have disabled it) but support IP fragmentation/reassembly should not be sending their IP packets with the DF bit set, and thus should not be receiving these ICMP error messages. Some TCP/IP stacks that do not implement PMTUD and that do not support IP fragmentation/ reassembly are known to send their packets with the DF bit set, and thus could legitimately receive these ICMP error messages.
ICMPv4タイプ3（Destination Unreachable）、コード4（フラグメンテーションが必要、DFビットセット）このエラーメッセージは、中間ノードがデータグラムをフラグメント化する必要があるが、IPヘッダーのDF（Do n't Fragment）ビットが設定されていることを示します。 TCPがPMTUDを実装している場合は「ソフトエラー」と見なされ、TCPがPMTUDを実装していない場合は「ハードエラー」と見なされます。 PMTUDを実装していない（または無効にしている）TCP / IPスタックがIPフラグメンテーション/再構成をサポートしている場合、DFビットが設定されたIPパケットを送信してはならず、これらのICMPエラーメッセージを受信してはなりません。 PMTUDを実装せず、IPフラグメンテーション/再構成をサポートしない一部のTCP / IPスタックは、DFビットが設定されたパケットを送信することがわかっているため、これらのICMPエラーメッセージを正当に受信する可能性があります。
ICMPv6 type 1 (Destination Unreachable), code 1 (communication with destination administratively prohibited)
ICMPv6タイプ1（宛先到達不能）、コード1（宛先との通信は管理上禁止されています）
This error message indicates that the destination is unreachable because of an administrative policy. For connection-oriented protocols such as TCP, one could expect to receive such an error as the result of a connection-establishment attempt. Receiving such an error for a connection in any of the synchronized states would mean that the administrative policy changed during the life of the connection. However, in the same way this error condition (which was not present when the connection was established) appeared, it could get solved in the near term.
このエラーメッセージは、管理ポリシーが原因で宛先に到達できないことを示しています。 TCPなどのコネクション型プロトコルの場合、接続確立の試行の結果としてこのようなエラーを受け取ることが予想されます。同期状態のいずれかで接続についてこのようなエラーを受信した場合は、接続の存続期間中に管理ポリシーが変更されたことを意味します。ただし、このエラー状態（接続が確立されたときには存在していなかった）が発生したのと同じように、短期的には解決する可能性があります。
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
ICMPv6タイプ1（Destination Unreachable）、コード4（port unreachable）
This error message is analogous to the ICMPv4 type 3 (Destination Unreachable), code 3 (port unreachable) error message discussed above. Therefore, the same considerations apply.
このエラーメッセージは、上記のICMPv4タイプ3（宛先到達不能）、コード3（ポート到達不能）エラーメッセージに似ています。したがって、同じ考慮事項が適用されます。
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that TCP SHOULD abort the corresponding connection in response to ICMPv4 messages of type 3 (Destination Unreachable), codes 2 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation needed and DF bit set). However, Section 3.2.2.1 states that TCP MUST accept an ICMPv4 port unreachable (type 3, code 3) for the same purpose as a RST. Therefore, for ICMPv4 messages of type 3, codes 2 and 4, there is room to go against the advice provided in the existing specifications, while in the case of ICMPv4 messages of type 3, code 3, there is ambiguity in the specifications that may or may not provide some room to go against that advice.
ホスト要件RFC [RFC1122]はセクション4.2.3.9で、タイプ3（宛先到達不能）、コード2（プロトコル到達不能）、3（ポート到達不能）、および4（フラグメンテーション）のICMPv4メッセージに応答して、対応する接続をTCPが打ち切る必要があると述べています。必要であり、DFビットセット）。ただし、3.2.2.1項では、TCPはRSTと同じ目的で到達不能なICMPv4ポート（タイプ3、コード3）を受け入れなければならない（MUST）と述べています。したがって、タイプ3、コード2および4のICMPv4メッセージの場合、既存の仕様で提供されているアドバイスに反対する余地がありますが、タイプ3、コード3のICMPv4メッセージの場合、仕様にあいまいさがあり、またはそのアドバイスに反対する余地を提供しないかもしれません。
Based on this analysis, most popular TCP implementations treat all ICMP "hard errors" received for connections in any of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT) as "soft errors". That is, they do not abort the corresponding connection upon receipt of them.
この分析に基づいて、最も一般的なTCP実装は、同期状態（確立、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、またはTIME-WAIT）を「ソフトエラー」として。つまり、対応する接続を受信しても中止しません。
Additionally, they do not extrapolate ICMP errors across TCP connections. This policy is based on the premise that TCP should be as robust as possible. Aborting the connection would be to ignore the valuable feature of the Internet -- that for many internal failures, it reconstructs its function without any disruption of the endpoints [RFC0816].
さらに、それらはTCP接続全体のICMPエラーを推定しません。このポリシーは、TCPができるだけ堅牢であるという前提に基づいています。接続を中止することは、インターネットの貴重な機能を無視することです-多くの内部障害の場合、エンドポイントを中断することなくその機能を再構築します[RFC0816]。
It should be noted that treating ICMP "hard errors" as "soft errors" for connections in any of the synchronized states may prevent TCP from responding quickly to a legitimate ICMP error message.
同期状態のいずれかでの接続のICMP「ハードエラー」を「ソフトエラー」として扱うと、TCPが正当なICMPエラーメッセージに迅速に応答できなくなる場合があることに注意してください。
It is interesting to note that, as ICMP error messages are transmitted unreliably, transport protocols should not depend on them for correct functioning. In the event one of these messages were legitimate, the corresponding connection would eventually time out. Also, applications may still be notified asynchronously about the error condition, and thus may still abort their connections on their own if they consider it appropriate.
ICMPエラーメッセージは信頼性の低い方法で送信されるため、トランスポートプロトコルが正しく機能するために、それらに依存するべきではないことに注意してください。これらのメッセージのいずれかが正当である場合、対応する接続は最終的にタイムアウトします。また、アプリケーションはエラー状態について非同期に通知される可能性があるため、適切であると判断した場合は、自分で接続を中止することができます。
In scenarios such as that in which an intermediate system sets the DF bit in the segments transmitted by a TCP that does not implement PMTUD, or the TCP at one of the endpoints of the connection is dynamically disabled, TCP would only abort the connection after a USER TIMEOUT [RFC0793], losing responsiveness. However, these scenarios are very unlikely in production environments, and it is probably preferable to potentially lose responsiveness for the sake of robustness. It should also be noted that applications may still be notified asynchronously about the error condition, and thus may still abort their connections on their own if they consider it appropriate.
中間システムがPMTUDを実装していないTCPによって送信されたセグメントにDFビットを設定するようなシナリオや、接続のエンドポイントの1つでTCPが動的に無効になっている場合、TCPは、ユーザータイムアウト[RFC0793]、応答性が失われています。ただし、これらのシナリオは本番環境では非常にまれであり、堅牢性のために応答性を失う可能性がある可能性があります。また、アプリケーションはエラー状態について非同期に通知される可能性があるため、適切であると判断した場合は、自分で接続を中止する可能性があることに注意してください。
In scenarios of multipath routing or route changes, failures in some (but not all) of the paths may elicit ICMP error messages that would likely not cause a connection abort if any of the counter-measures described in this section were implemented. However, aborting the connection would be to ignore the valuable feature of the Internet -- that for many internal failures, it reconstructs its function without any disruption of the endpoints [RFC0816]. That is, communication should survive if there is still a working path to the destination system [DClark]. Additionally, applications may still be notified asynchronously about the error condition, and thus may still abort their connections on their own if they consider it appropriate.
マルチパスルーティングまたはルート変更のシナリオでは、パスの一部（すべてではない）で障害が発生すると、このセクションで説明する対策のいずれかが実装されている場合、接続の中止を引き起こさない可能性が高いICMPエラーメッセージが表示されることがあります。ただし、接続を中止すると、インターネットの貴重な機能が無視されます。多くの内部障害の場合、エンドポイントを中断することなく機能を再構築します[RFC0816]。つまり、宛先システム[DClark]へのパスがまだ機能している場合、通信は存続するはずです。さらに、アプリケーションは引き続きエラー状態について非同期に通知される可能性があり、したがって適切であると考える場合は、自分で接続を中断することができます。
This counter-measure has been implemented in BSD-derived TCP/IP implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more than ten years [Wright][McKusick]. The Linux kernel has also implemented this policy for more than ten years [Linux].
この対策は、BSD派生のTCP / IP実装（[FreeBSD]、[NetBSD]、[OpenBSD]など）で10年以上実装されています[Wright] [McKusick]。 Linuxカーネルもこのポリシーを10年以上実装しています[Linux]。
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that hosts MUST react to ICMPv4 Source Quench messages by slowing transmission on the connection. Thus, an attacker could send ICMPv4 Source Quench (type 4, code 0) messages to a TCP endpoint to make it reduce the rate at which it sends data to the other endpoint of the connection. [RFC1122] further adds that the RECOMMENDED procedure is to put the corresponding connection in the slow-start phase of TCP's congestion control algorithm [RFC5681]. In the case of those implementations that use an initial congestion window of one segment, a sustained attack would reduce the throughput of the attacked connection to about SMSS (Sender Maximum Segment Size) [RFC5681] bytes per RTT (round-trip time). The throughput achieved during an attack might be a little higher if a larger initial congestion window is in use [RFC3390].
ホスト要件RFC [RFC1122]はセクション4.2.3.9で、ホストは接続での送信を遅くすることによってICMPv4 Source Quenchメッセージに反応する必要があると述べています。したがって、攻撃者はICMPv4 Source Quench（タイプ4、コード0）メッセージをTCPエンドポイントに送信して、接続の他のエンドポイントにデータを送信するレートを低下させる可能性があります。 [RFC1122]はさらに、RECOMMENDEDプロシージャが対応する接続をTCPの輻輳制御アルゴリズム[RFC5681]のスロースタートフェーズに置くことを追加しています。 1つのセグメントの初期輻輳ウィンドウを使用するこれらの実装の場合、持続的な攻撃により、攻撃された接続のスループットがRTT（往復時間）あたり約SMSS（送信者最大セグメントサイズ）[RFC5681]バイトに減少します。大きな初期輻輳ウィンドウが使用されている場合、攻撃中に達成されるスループットは少し高くなる可能性があります[RFC3390]。
As discussed in the "Requirements for IP Version 4 Routers" RFC
[RFC1812], research seems to suggest that ICMPv4 Source Quench
messages are an ineffective (and unfair) antidote for congestion.
[RFC1812] further states that routers SHOULD NOT send ICMPv4 Source
Quench messages in response to congestion. Furthermore, TCP
implements its own congestion control mechanisms ([RFC5681]
[RFC3168]) that do not depend on ICMPv4 Source Quench messages.
Based on this reasoning, a large number of implementations completely ignore ICMPv4 Source Quench messages meant for TCP connections. This behavior has been implemented in, at least, Linux [Linux] since 2004, and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since 2005. However, it must be noted that this behavior violates the requirement in [RFC1122] to react to ICMPv4 Source Quench messages by slowing transmission on the connection.
この推論に基づいて、多数の実装は、TCP接続用のICMPv4 Source Quenchメッセージを完全に無視します。この動作は、少なくとも2004年以降のLinux [Linux]と、2005年以降のFreeBSD [FreeBSD]、NetBSD [NetBSD]、およびOpenBSD [OpenBSD]に実装されています。ただし、この動作は以下の要件に違反していることに注意してください。 [RFC1122]接続での送信を遅くすることにより、ICMPv4 Source Quenchメッセージに反応します。
When one IP system has a large amount of data to send to another system, the data will be transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU) and is equal to the minimum of the MTUs of each hop in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP systems determine the Path MTU of an arbitrary internet path. [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and IPv6, respectively.
1つのIPシステムに別のシステムに送信する大量のデータがある場合、データは一連のIPデータグラムとして送信されます。通常、これらのデータグラムは、ソースから宛先へのパスに沿ったどこでもフラグメント化を必要としない最大サイズであることが望ましいです。このデータグラムサイズは、パスMTU（PMTU）と呼ばれ、パス内の各ホップのMTUの最小値と同じです。 「パスMTUディスカバリー」（PMTUD）と呼ばれる手法により、IPシステムは任意のインターネットパスのパスMTUを判別できます。 [RFC1191]と[RFC1981]は、それぞれIPv4とIPv6のPMTUDメカニズムを指定しています。
The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the IP header to dynamically discover the Path MTU. The basic idea behind the PMTUD mechanism is that a source system assumes that the MTU of the path is that of the first hop, and sends all its datagrams with the DF bit set. If any of the datagrams is too large to be forwarded without fragmentation by some intermediate router, the router will discard the corresponding datagram and will return an ICMPv4 "Destination Unreachable, fragmentation needed and DF set" (type 3, code 4) error message to the sending system. This message will report the MTU of the constricting hop, so that the sending system can reduce the assumed Path-MTU accordingly.
IPv4のPMTUDメカニズムは、IPヘッダーのDo n't Fragment（DF）ビットを使用して、パスMTUを動的に検出します。 PMTUDメカニズムの背後にある基本的な考え方は、ソースシステムはパスのMTUが最初のホップのMTUであると想定し、すべてのデータグラムをDFビットセットで送信するというものです。データグラムのいずれかが大きすぎて、一部の中間ルーターによる断片化なしでは転送できない場合、ルーターは対応するデータグラムを破棄し、ICMPv4 "宛先に到達できません。断片化が必要で、DFセット"（タイプ3、コード4）のエラーメッセージを返します。送信システム。このメッセージは圧縮ホップのMTUを報告するため、送信システムは想定されるPath-MTUを適宜削減できます。
For IPv6, intermediate systems do not fragment packets. Thus, there's an "implicit" DF bit set in every packet sent on a network. If any of the datagrams is too large to be forwarded without fragmentation by some intermediate router, the router will discard the corresponding datagram, and will return an ICMPv6 "Packet Too Big" (type 2, code 0) error message to the sending system. This message will report the MTU of the constricting hop, so that the sending system can reduce the assumed Path-MTU accordingly.
IPv6の場合、中間システムはパケットをフラグメント化しません。したがって、ネットワーク上で送信されるすべてのパケットには、「暗黙の」DFビットが設定されています。データグラムのいずれかが大きすぎて、一部の中間ルーターによる断片化なしでは転送できない場合、ルーターは対応するデータグラムを破棄し、ICMPv6 "パケットが大きすぎます"（タイプ2、コード0）エラーメッセージを送信側システムに返します。このメッセージは圧縮ホップのMTUを報告するため、送信システムは想定されるPath-MTUを適宜削減できます。
As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery mechanism can be used to attack TCP. An attacker could send a crafted ICMPv4 "Destination Unreachable, fragmentation needed and DF set" packet (or their ICMPv6 counterpart) to the sending system, advertising a small Next-Hop MTU. As a result, the attacked system would reduce the size of the packets it sends for the corresponding connection accordingly.
[RFC1191]と[RFC1981]の両方で説明されているように、Path-MTU Discoveryメカニズムを使用してTCPを攻撃できます。攻撃者は細工したICMPv4「宛先到達不能、フラグメンテーションが必要、DFセット」パケット（またはそれらのICMPv6対応）を送信システムに送信し、小さなネクストホップMTUをアドバタイズする可能性があります。その結果、攻撃されたシステムは、対応する接続に送信するパケットのサイズを適宜縮小します。
The effect of this attack is two-fold. On one hand, it will increase the headers/data ratio, thus increasing the overhead needed to send data to the remote TCP endpoint. On the other hand, if the attacked system wanted to keep the same throughput it was achieving before being attacked, it would have to increase the packet rate. On virtually all systems, this will lead to an increased processing overhead, thus degrading the overall system performance.
この攻撃の影響は2つあります。一方では、ヘッダーとデータの比率が高くなるため、リモートTCPエンドポイントにデータを送信するために必要なオーバーヘッドが増加します。一方、攻撃されるシステムが攻撃される前に達成していたのと同じスループットを維持したい場合は、パケットレートを上げる必要があります。事実上すべてのシステムで、これにより処理オーバーヘッドが増加し、システム全体のパフォーマンスが低下します。
A particular scenario that may take place is one in which an attacker reports a Next-Hop MTU smaller than or equal to the amount of bytes needed for headers (IP header, plus TCP header). For example, if the attacker reports a Next-Hop MTU of 68 bytes, and the amount of bytes used for headers (IP header, plus TCP header) is larger than 68 bytes, the assumed Path-MTU will not even allow the attacked system to send a single byte of application data without fragmentation. This particular scenario might lead to unpredictable results. Another possible scenario is one in which a TCP connection is being secured by means of IPsec. If the Next-Hop MTU reported by the attacker is smaller than the amount of bytes needed for headers (IP and IPsec, in this case), the assumed Path-MTU will not even allow the attacked system to send a single byte of the TCP header without fragmentation. This is another scenario that may lead to unpredictable results.
発生する可能性がある特定のシナリオは、攻撃者がヘッダー（IPヘッダーとTCPヘッダー）に必要なバイト数以下のネクストホップMTUを報告するシナリオです。たとえば、攻撃者が68バイトのネクストホップMTUを報告し、ヘッダー（IPヘッダーとTCPヘッダー）に使用されるバイト数が68バイトより大きい場合、想定されるパスMTUは攻撃されたシステムを許可しません断片化せずに1バイトのアプリケーションデータを送信する。この特定のシナリオでは、予期しない結果が生じる可能性があります。別の考えられるシナリオは、TCP接続がIPsecによって保護されているシナリオです。攻撃者によって報告されたネクストホップMTUがヘッダー（この場合はIPおよびIPsec）に必要なバイト数よりも小さい場合、想定されるパスMTUは、攻撃されたシステムがTCPの1バイトを送信することさえ許可しません断片化のないヘッダー。これは、予期しない結果をもたらす可能性のある別のシナリオです。
For IPv4, the reported Next-Hop MTU could be as small as 68 octets, as [RFC0791] requires every internet module to be able to forward a datagram of 68 octets without further fragmentation. For IPv6, while the required minimum IPv6 MTU is 1280, the reported Next-Hop MTU can be smaller than 1280 octets [RFC2460]. If the reported Next-Hop MTU is smaller than the minimum IPv6 MTU, the receiving host is not required to reduce the Path-MTU to a value smaller than 1280, but is required to include a fragmentation header in the outgoing packets to that destination from that moment on.
IPv4の場合、[RFC0791]はすべてのインターネットモジュールがさらに断片化することなく68オクテットのデータグラムを転送できるようにする必要があるため、報告されるネクストホップMTUは68オクテットまで小さくなる可能性があります。 IPv6の場合、必要な最小IPv6 MTUは1280ですが、報告されるNext-Hop MTUは1280オクテットよりも小さい場合があります[RFC2460]。報告されたNext-Hop MTUが最小IPv6 MTUより小さい場合、受信ホストはPath-MTUを1280より小さい値に減らす必要はありませんが、その宛先への送信パケットにフラグメンテーションヘッダーを含める必要がありますその瞬間。
The IETF has standardized a Path-MTU Discovery mechanism called "Packetization Layer Path MTU Discovery" (PLPMTUD) that does not depend on ICMP error messages. Implementation of the aforementioned mechanism in replacement of the traditional PMTUD (specified in [RFC1191] and [RFC1981]) eliminates this vulnerability. However, it can also lead to an increase in PMTUD convergence time.
IETFは、ICMPエラーメッセージに依存しない「Packetization Layer Path MTU Discovery」（PLPMTUD）と呼ばれるPath-MTU Discoveryメカニズムを標準化しました。従来のPMTUD（[RFC1191]および[RFC1981]で指定）の代わりに前述のメカニズムを実装すると、この脆弱性が排除されます。ただし、PMTUDコンバージェンス時間の増加にもつながる可能性があります。
This section describes a modification to the PMTUD mechanism specified in [RFC1191] and [RFC1981] that has been incorporated in OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the blind performance-degrading attack described in Section 7.1. The described counter-measure basically disregards ICMP messages when a connection makes progress, without violating any of the requirements stated in [RFC1191] and [RFC1981].
このセクションでは、[RFC1191]と[RFC1981]で指定されたPMTUDメカニズムの変更点について説明します。これは、OpenBSDとNetBSD（2005以降）に組み込まれ、セクション7.1で説明されているブラインドパフォーマンス低下攻撃に対するTCPの耐性を向上させます。 [RFC1191]と[RFC1981]で述べられている要件に違反することなく、接続が進行するとき、説明された対応策は基本的にICMPメッセージを無視します。
Henceforth, we will refer to both ICMPv4 "fragmentation needed and DF bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too Big" messages.
以降では、ICMPv4の「フラグメンテーションが必要でDFビットが設定されています」メッセージとICMPv6の「パケットが大きすぎる」メッセージの両方を「ICMPパケットが大きすぎる」メッセージと呼びます。
In addition to the general validation check described in Section 4.1, these implementations include a modification to TCP's reaction to ICMP "Packet Too Big" error messages that disregards them when a connection makes progress, and honors them only after the corresponding data have been retransmitted a specified number of times. This means that upon receipt of an ICMP "Packet Too Big" error message, TCP just records this information, and honors it only when the corresponding data have already been retransmitted a specified number of times.
セクション4.1で説明されている一般的な検証チェックに加えて、これらの実装には、接続が進行するときに無視して対応するデータが再送信された後にのみそれらを尊重するICMP「パケットが大きすぎる」エラーメッセージに対するTCPの反応に対する変更が含まれます。指定された回数。つまり、ICMPの「Packet Too Big」エラーメッセージを受信すると、TCPはこの情報を記録し、対応するデータが指定された回数だけ再送信された場合にのみそれを尊重します。
While this basic policy would greatly mitigate the impact of the attack against the PMTUD mechanism, it would also mean that it might take TCP more time to discover the Path-MTU for a TCP connection. This would be particularly annoying for connections that have just been established, as it might take TCP several transmission attempts (and the corresponding timeouts) before it discovers the PMTU for the corresponding connection. Thus, this policy would increase the time it takes for data to begin to be received at the destination host.
この基本的なポリシーは、PMTUDメカニズムに対する攻撃の影響を大幅に軽減しますが、TCP接続のパスMTUを検出するためにTCPにさらに時間がかかる可能性があることも意味します。これは、TCPが対応する接続のPMTUを検出する前に、いくつかの送信試行（および対応するタイムアウト）を行う可能性があるため、確立されたばかりの接続では特に厄介です。したがって、このポリシーでは、宛先ホストでデータが受信され始めるまでにかかる時間が長くなります。
In order to protect TCP from the attack against the PMTUD mechanism, while still allowing TCP to quickly determine the initial Path-MTU for a connection, the aforementioned implementations have divided the traditional PMTUD mechanism into two stages: Initial Path-MTU Discovery and Path-MTU Update.
PMTUDメカニズムに対する攻撃からTCPを保護するために、TCPが接続の初期パスMTUをすばやく決定できるようにする一方で、前述の実装では、従来のPMTUDメカニズムを2つのステージに分けました。初期パスMTU検出とパス- MTUアップデート。
The Initial Path-MTU Discovery stage is when TCP tries to send segments that are larger than the ones that have so far been sent and acknowledged for this connection. That is, in the Initial Path-MTU Discovery stage, TCP has no record of these large segments getting to the destination host, and thus these implementations believe the network when it reports that these packets are too large to reach the destination host without being fragmented.
最初のパスMTUディスカバリステージは、TCPがこの接続に対してこれまでに送信および確認されたセグメントよりも大きいセグメントを送信しようとするときです。つまり、初期パスMTUディスカバリステージでは、TCPには宛先ホストに到達するこれらの大きなセグメントの記録がないため、これらの実装は、これらのパケットがフラグメント化されずに宛先ホストに到達するには大きすぎると報告したときにネットワークを信じます。
The Path-MTU Update stage is when TCP tries to send segments that are equal to or smaller than the ones that have already been sent and acknowledged for this connection. During the Path-MTU Update stage, TCP already has knowledge of the estimated Path-MTU for the given connection. Thus, in this case, these implementations are more cautious with the errors being reported by the network.
Path-MTU Updateステージは、TCPが、この接続に対してすでに送信および確認済みのセグメントと同じかそれよりも小さいセグメントを送信しようとするときです。 Path-MTUの更新段階では、TCPは特定の接続の推定Path-MTUをすでに知っています。したがって、この場合、これらの実装は、ネットワークによって報告されるエラーに注意が必要です。
In order to allow TCP to distinguish segments between those performing Initial Path-MTU Discovery and those performing Path-MTU Update, two new variables are introduced to TCP: maxsizesent and maxsizeacked.
TCPが初期パスMTUディスカバリーを実行するセグメントとパスMTU更新を実行するセグメントの間でセグメントを区別できるようにするために、2つの新しい変数、maxsizesentとmaxsizeackedがTCPに導入されています。
The maxsizesent variable holds the size (in octets) of the largest packet that has so far been sent for this connection. It is initialized to 68 (the minimum IPv4 MTU) when the underlying Internet Protocol is IPv4, and is initialized to 1280 (the minimum IPv6 MTU) when the underlying Internet Protocol is IPv6. Whenever a packet larger than maxsizesent octets is sent, maxsizesent is set to that value.
maxsizesent変数は、この接続でこれまでに送信された最大のパケットのサイズ（オクテット単位）を保持します。基になるインターネットプロトコルがIPv4の場合は68（最小IPv4 MTU）に初期化され、基になるインターネットプロトコルがIPv6の場合は1280（最小IPv6 MTU）に初期化されます。 maxsizesentオクテットより大きいパケットが送信されるときはいつでも、maxsizesentはその値に設定されます。
On the other hand, maxsizeacked holds the size (in octets) of the largest packet (data, plus headers) that has so far been acknowledged for this connection. It is initialized to 68 (the minimum IPv4 MTU) when the underlying Internet Protocol is IPv4, and is initialized to 1280 (the minimum IPv6 MTU) when the underlying Internet Protocol is IPv6. Whenever an acknowledgement for a packet larger than maxsizeacked octets is received, maxsizeacked is set to the size of that acknowledged packet. Note that because of TCP's cumulative acknowledgement, a single ACK may acknowledge the receipt of more than one packet. When that happens, the algorithm may "incorrectly" assume it is in the "Path-MTU Update" stage, rather than the "Initial Path-MTU Discovery" stage (as described below).
一方、maxsizeackedは、この接続でこれまでに確認された最大のパケット（データとヘッダー）のサイズ（オクテット単位）を保持します。基になるインターネットプロトコルがIPv4の場合は68（最小IPv4 MTU）に初期化され、基になるインターネットプロトコルがIPv6の場合は1280（最小IPv6 MTU）に初期化されます。 maxsizeackedオクテットより大きいパケットの確認応答が受信されると、maxsizeackedはその確認応答されたパケットのサイズに設定されます。 TCPの累積確認応答のため、1つのACKが複数のパケットの受信を確認する場合があることに注意してください。その場合、アルゴリズムは「初期パスMTUディスカバリ」ステージではなく、「パスMTUアップデート」ステージにあると誤って想定します（以下で説明します）。
Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop MTU claimed by the ICMP message (henceforth "claimedmtu") is compared with maxsizesent. If claimedmtu is larger than maxsizesent, then the ICMP error message is silently discarded. The rationale for this is that the ICMP error message cannot be legitimate if it claims to have been triggered by a packet larger than the largest packet we have so far sent for this connection.
ICMP "パケットが大きすぎます"エラーメッセージを受信すると、ICMPメッセージ（以降は "claimedmtu"）によって要求された次ホップMTUがmaxsizesentと比較されます。 Claimedmtuがmaxsizesentより大きい場合、ICMPエラーメッセージは通知なく破棄されます。この理由は、ICMPエラーメッセージが、この接続に対してこれまでに送信した最大のパケットよりも大きいパケットによってトリガーされたと主張する場合、正当なものではないということです。
If this check is passed, claimedmtu is compared with maxsizeacked. If claimedmtu is equal to or larger than maxsizeacked, TCP is supposed to be at the Initial Path-MTU Discovery stage, and thus the ICMP "Packet Too Big" error message is honored immediately. That is, the assumed Path-MTU is updated according to the Next-Hop MTU claimed in the ICMP error message. Also, maxsizesent is reset to the minimum MTU of the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
このチェックに合格すると、claimedmtuがmaxsizeackedと比較されます。 Claimedmtuがmaxsizeacked以上の場合、TCPは初期パスMTUディスカバリステージにあると考えられるため、ICMPの「Packet Too Big」エラーメッセージがすぐに表示されます。つまり、想定されるPath-MTUは、ICMPエラーメッセージで要求されたNext-Hop MTUに従って更新されます。また、maxsizesentは、使用中のインターネットプロトコルの最小MTU（IPv4の場合は68、IPv6の場合は1280）にリセットされます。
On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is supposed to be in the Path-MTU Update stage. At this stage, these implementations are more cautious with the errors being reported by the network, and therefore just record the received error message, and delay the update of the assumed Path-MTU.
一方、claimedmtuがmaxsizeackedよりも小さい場合、TCPはPath-MTU Updateステージにあると考えられます。この段階では、これらの実装はネットワークから報告されるエラーに注意を払い、したがって受信したエラーメッセージを記録するだけで、想定されるパスMTUの更新を遅らせます。
To perform this delay, one new variable and one new parameter are introduced to TCP: nsegrto and MAXSEGRTO. The nsegrto variable holds the number of times a specified segment has timed out. It is initialized to zero, and is incremented by one every time the corresponding segment times out. MAXSEGRTO specifies the number of times a given segment must time out before an ICMP "Packet Too Big" error message can be honored, and can be set, in principle, to any value greater than or equal to 0.
この遅延を実行するために、1つの新しい変数と1つの新しいパラメーターがTCPに導入されました：nsegrtoおよびMAXSEGRTO。 nsegrto変数は、指定されたセグメントがタイムアウトした回数を保持します。これはゼロに初期化され、対応するセグメントがタイムアウトするたびに1ずつ増加します。 MAXSEGRTOは、ICMPの「Packet Too Big」エラーメッセージが受け入れられ、原則として0以上の任意の値に設定できるようになるまでに、特定のセグメントがタイムアウトする必要がある回数を指定します。
Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a pending ICMP "Packet Too Big" error message, the corresponding error message is processed. At that point, maxsizeacked is set to claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for IPv6).
したがって、nsegrtoがMAXSEGRTO以上で、保留中のICMP "Packet Too Big"エラーメッセージがある場合、対応するエラーメッセージが処理されます。その時点で、maxsizeackedはClaimedmtuに設定され、maxsizesentは68（IPv4の場合）または1280（IPv6の場合）に設定されます。
If, while there is a pending ICMP "Packet Too Big" error message, the TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK that acknowledges that sequence number is received), then the "pending error" condition is cleared.
保留中のICMP "Packet Too Big"エラーメッセージがある間に、保留中のメッセージによって要求されたTCP SEQが確認される（つまり、そのシーケンス番号を確認するACKが受信される）と、 "保留中のエラー"状態は解消されます。
The rationale behind performing this delayed processing of ICMP "Packet Too Big" messages is that if there is progress on the connection, the ICMP "Packet Too Big" errors must be a false claim. By checking for progress on the connection, rather than just for staleness of the received ICMP messages, TCP is protected from attack even if the offending ICMP messages are "in window", and as a corollary, is made more robust to spurious ICMP messages triggered by, for example, corrupted TCP segments.
ICMPの「Packet Too Big」メッセージの遅延処理を実行する背後にある根拠は、接続に進行状況がある場合、ICMPの「Packet Too Big」エラーは誤った主張でなければならないということです。受信したICMPメッセージの古さだけでなく、接続の進行状況をチェックすることにより、問題のICMPメッセージが「ウィンドウ内」にある場合でも、TCPは攻撃から保護され、結果として、偽のICMPメッセージがトリガーされた場合により強力になります。たとえば、破損したTCPセグメントによって。
MAXSEGRTO can be set, in principle, to any value greater than or equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A MAXSEGRTO of 1 provides enough protection for most cases. In any case, implementations are free to choose higher values for this constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed in the received ICMP "Packet Too Big" message. That is, higher values for MAXSEGRTO could be imposed when the received ICMP "Packet Too Big" message claims a Next-Hop MTU that is smaller than some specified value. Both OpenBSD and NetBSD set MAXSEGRTO to 1.
MAXSEGRTOは、原則として0以上の任意の値に設定できます。MAXSEGRTOを0に設定すると、TCPは[RFC1191]および[RFC1981]で定義されている従来のPMTUDメカニズムを実行します。 MAXSEGRTO 1は、ほとんどの場合に十分な保護を提供します。いずれの場合も、実装はこの定数に対してより高い値を自由に選択できます。 MAXSEGRTOは、受信したICMP "Packet Too Big"メッセージで要求されたNext-Hop MTUの関数である可能性があります。つまり、受信したICMP "Packet Too Big"メッセージで、指定された値よりも小さいネクストホップMTUが要求された場合、MAXSEGRTOの値が高くなる可能性があります。 OpenBSDとNetBSDはどちらもMAXSEGRTOを1に設定します。
In the event a higher level of protection is desired at the expense of a higher delay in the discovery of the Path-MTU, an implementation could consider TCP to always be in the Path-MTU Update stage, thus always delaying the update of the assumed Path-MTU.
Path-MTUのディスカバリーの遅延が大きくなることを犠牲にして、より高いレベルの保護が必要な場合、実装では、TCPが常にPath-MTU更新ステージにあると見なすことができるため、想定される更新を常に遅延させます。パスMTU。
Section 7.3 shows this counter-measure in action. Section 7.4 shows this counter-measure in pseudo-code.
7.3節では、この対策の実際を示します。セクション7.4は、この対策を疑似コードで示しています。
It is important to note that the mechanism described in this section is an improvement to the current Path-MTU discovery mechanism, to mitigate its security implications. The current PMTUD mechanism, as specified by [RFC1191] and [RFC1981], still suffers from some functionality problems [RFC2923] that this document does not aim to address. A mechanism that addresses those issues is described in [RFC4821].
このセクションで説明するメカニズムは、セキュリティへの影響を軽減するために、現在のパスMTU検出メカニズムを改善したものであることに注意することが重要です。 [RFC1191]と[RFC1981]で指定されている現在のPMTUDメカニズムには、このドキュメントで取り上げない機能上の問題[RFC2923]があります。これらの問題に対処するメカニズムは、[RFC4821]で説明されています。
This section illustrates the operation of the counter-measure for the ICMP attack against the PMTUD mechanism that has been implemented in OpenBSD and NetBSD. It shows both how the fix protects TCP from being attacked and how the counter-measure works in normal scenarios. As discussed in Section 7.2, this section assumes the PMTUD-specific counter-measure is implemented in addition to the TCP sequence number checking described in Section 4.1.
このセクションでは、OpenBSDとNetBSDに実装されているPMTUDメカニズムに対するICMP攻撃に対する対策の操作を説明します。この修正により、TCPが攻撃から保護される方法と、通常のシナリオでの対策がどのように機能するかが示されます。セクション7.2で説明したように、このセクションでは、セクション4.1で説明されているTCPシーケンス番号チェックに加えて、PMTUD固有の対策が実装されていることを前提としています。
Figure 1 illustrates a hypothetical scenario in which two hosts are connected by means of three intermediate routers. It also shows the MTU of each hypothetical hop. All the following subsections assume the network setup of this figure.
図1は、2つのホストが3つの中間ルーターによって接続されている架空のシナリオを示しています。また、各仮想ホップのMTUも表示されます。以下のすべてのサブセクションでは、この図のネットワーク設定を想定しています。
Also, for simplicity's sake, all subsections assume an IP header of 20 octets and a TCP header of 20 octets. Thus, for example, when the PMTU is assumed to be 1500 octets, TCP will send segments that contain, at most, 1460 octets of data.
また、簡単にするために、すべてのサブセクションでは、20オクテットのIPヘッダーと20オクテットのTCPヘッダーを想定しています。したがって、たとえば、PMTUが1500オクテットであると想定されている場合、TCPは最大で1460オクテットのデータを含むセグメントを送信します。
For simplicity's sake, all the following subsections assume the TCP implementation at Host 1 (H1) has chosen a MAXSEGRTO of 1.
簡単にするために、以下のすべてのサブセクションでは、ホスト1（H1）でのTCP実装がMAXSEGRTOとして1を選択していると想定しています。
+----+ +----+ +----+ +----+ +----+
| H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
+----+ +----+ +----+ +----+ +----+
MTU=4464 MTU=2048 MTU=1500 MTU=4464
Figure 1: Hypothetical Scenario
図1：仮説シナリオ
This subsection shows the counter-measure in normal operation, when a TCP connection is used for bulk transfers. That is, it shows how the counter-measure works when there is no attack taking place and a TCP connection is used for transferring large amounts of data. This section assumes that just after the connection is established, one of the TCP endpoints begins to transfer data in packets that are as large as possible.
この節では、TCPコネクションを使用して一括転送する場合の通常運用時の対策を示します。つまり、攻撃が発生せず、TCP接続を使用して大量のデータを転送する場合の対策がどのように機能するかを示しています。このセクションでは、接続が確立された直後に、TCPエンドポイントの1つが可能な限り大きいパケットでデータの転送を開始すると想定しています。
Host 1 Host 2
ホスト1ホスト2
1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> -->
5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1
6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> -->
7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2
8. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=1460> -->
9. <-- <SEQ=X+1><ACK=1561><CTL=ACK> <--
Figure 2: Normal Operation for Bulk Transfers
図2：バルク転送の通常の操作
The nsegrto variable is initialized to zero. Both maxsizeacked and maxsizesent are initialized to the minimum MTU for the Internet Protocol being used (68 for IPv4, and 1280 for IPv6).
nsegrto変数はゼロに初期化されます。 maxsizeackedとmaxsizesentの両方が、使用されているインターネットプロトコルの最小MTU（IPv4の場合は68、IPv6の場合は1280）に初期化されます。
In lines 1 to 3, the three-way handshake takes place, and the connection is established. In line 4, H1 tries to send a full-sized TCP segment. As described by [RFC1191] and [RFC1981], in this case, TCP will try to send a segment with 4424 bytes of data, which will result in an IP packet of 4464 octets. Therefore, maxsizesent is set to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too Big" error message.
1行目から3行目では、3ウェイハンドシェイクが行われ、接続が確立されます。 4行目で、H1はフルサイズのTCPセグメントを送信しようとします。 [RFC1191]と[RFC1981]で説明されているように、この場合、TCPは4424バイトのデータを含むセグメントを送信しようとし、その結果IPパケットは4464オクテットになります。したがって、maxsizesentは4464に設定されます。パケットがR1に到達すると、ICMP "Packet Too Big"エラーメッセージが表示されます。
In line 5, H1 receives the ICMP error message, which reports a Next-Hop MTU of 2048 octets. After performing the TCP sequence number check described in Section 4.1, the Next-Hop MTU reported by the ICMP error message (claimedmtu) is compared with maxsizesent. As it is smaller than maxsizesent, it passes the check, and thus is then compared with maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes that the corresponding TCP segment was performing the Initial PMTU Discovery. Therefore, the TCP at H1 honors the ICMP message by updating the assumed Path-MTU. The maxsizesent variable is reset to the minimum MTU of the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
5行目で、H1はICMPエラーメッセージを受信し、2048オクテットのネクストホップMTUを報告します。セクション4.1で説明されているTCPシーケンス番号チェックを実行した後、ICMPエラーメッセージ（claimedmtu）によって報告されたネクストホップMTUがmaxsizesentと比較されます。 maxsizesentよりも小さいため、チェックに合格し、maxsizeackedと比較されます。 Claimedmtuがmaxsizeackedよりも大きいため、TCPは、対応するTCPセグメントが初期PMTU検出を実行していたと想定します。したがって、H1のTCPは、想定されるPath-MTUを更新することにより、ICMPメッセージを尊重します。 maxsizesent変数は、使用中のインターネットプロトコルの最小MTU（IPv4の場合は68、IPv6の場合は1280）にリセットされます。
In line 6, the TCP at H1 sends a segment with 2008 bytes of data, which results in an IP packet of 2048 octets. The maxsizesent variable is thus set to 2008 bytes. When the packet reaches R2, it elicits an ICMP "Packet Too Big" error message.
6行目で、H1のTCPは2008バイトのデータを含むセグメントを送信し、その結果、2048オクテットのIPパケットになります。したがって、maxsizesent変数は2008バイトに設定されます。パケットがR2に到達すると、ICMP "Packet Too Big"エラーメッセージが表示されます。
In line 7, H1 receives the ICMP error message, which reports a Next-Hop MTU of 1500 octets. After performing the TCP sequence number check, the Next-Hop MTU reported by the ICMP error message (claimedmtu) is compared with maxsizesent. As it is smaller than maxsizesent, it passes the check, and thus is then compared with maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes that the corresponding TCP segment was performing the Initial PMTU Discovery. Therefore, the TCP at H1 honors the ICMP message by updating the assumed Path-MTU. The maxsizesent variable is reset to the minimum MTU of the Internet Protocol in use.
7行目で、H1はICMPエラーメッセージを受信します。このメッセージは、1500オクテットのネクストホップMTUを報告します。 TCPシーケンス番号チェックを実行した後、ICMPエラーメッセージ（claimedmtu）によって報告されたネクストホップMTUがmaxsizesentと比較されます。 maxsizesentよりも小さいため、チェックに合格し、maxsizeackedと比較されます。 Claimedmtuがmaxsizeackedよりも大きいため、TCPは、対応するTCPセグメントが初期PMTU検出を実行していたと想定します。したがって、H1のTCPは、想定されるPath-MTUを更新することにより、ICMPメッセージを尊重します。 maxsizesent変数は、使用中のインターネットプロトコルの最小MTUにリセットされます。
In line 8, the TCP at H1 sends a segment with 1460 bytes of data, which results in an IP packet of 1500 octets. Thus, maxsizesent is set to 1500. This packet reaches H2, where it elicits an acknowledgement (ACK) segment.
8行目では、H1のTCPが1460バイトのデータを含むセグメントを送信し、1500オクテットのIPパケットが生成されます。したがって、maxsizesentは1500に設定されます。このパケットはH2に到達し、確認応答（ACK）セグメントを引き出します。
In line 9, H1 finally gets the acknowledgement for the data segment. As the corresponding packet was larger than maxsizeacked, TCP updates maxsizeacked, setting it to 1500. At this point, TCP has discovered the Path-MTU for this TCP connection.
9行目で、H1は最終的にデータセグメントの確認応答を取得します。対応するパケットがmaxsizeackedよりも大きかったため、TCPはmaxsizeackedを更新して1500に設定します。この時点で、TCPはこのTCP接続のPath-MTUを検出しました。
Let us suppose a TCP connection between H1 and H2 has already been established, and that the PMTU for the connection has already been discovered to be 1500. At this point, both maxsizesent and maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose some time later the PMTU decreases to 1492. For simplicity, let us suppose that the Path-MTU has decreased because the MTU of the link between R2 and R3 has decreased from 1500 to 1492. Figure 3 illustrates how the counter-measure would work in this scenario.
H1とH2の間のTCP接続が既に確立されており、接続のPMTUが1500であることが既に検出されていると仮定します。この時点で、maxsizesentとmaxsizeackedはどちらも1500に等しく、nsegrtoは0に等しくなります。しばらくしてPMTUが1492に減少したとします。簡単にするために、R2とR3の間のリンクのMTUが1500から1492に減少したため、Path-MTUが減少したと仮定します。図3は、対策がどのように機能するかを示していますこのシナリオでは。
Host 1 Host 2
ホスト1ホスト2
1. (Path-MTU decreases)
2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2
4. (Segment times out)
5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> -->
6. <-- <SEQ=X><ACK=1552><CTL=ACK> <--
Figure 3: Operation during Path-MTU Changes
図3：パスMTU変更中の動作
In line 1, the Path-MTU for this connection decreases from 1500 to 1492. In line 2, the TCP at H1, without being aware of the Path-MTU change, sends a 1500-byte packet to H2. When the packet reaches R2, it elicits an ICMP "Packet Too Big" error message.
1行目では、この接続のPath-MTUは1500から1492に減少しています。2行目では、H1のTCPは、Path-MTUの変更を認識せずに、1500バイトのパケットをH2に送信します。パケットがR2に到達すると、ICMP "Packet Too Big"エラーメッセージが表示されます。
In line 3, H1 receives the ICMP error message, which reports a Next-Hop MTU of 1492 octets. After performing the TCP sequence number check, the Next-Hop MTU reported by the ICMP error message (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller than maxsizesent, it is then compared with maxsizeacked. As claimedmtu is smaller than maxsizeacked (full-sized packets were getting to the remote endpoint), this packet is assumed to be performing Path-MTU Update, and a "pending error" condition is recorded.
3行目で、H1はICMPエラーメッセージを受信します。このメッセージは、1492オクテットのネクストホップMTUを報告します。 TCPシーケンス番号チェックを実行した後、ICMPエラーメッセージ（claimedmtu）によって報告されたネクストホップMTUがmaxsizesentと比較されます。 Claimedmtuはmaxsizesentよりも小さいため、maxsizeackedと比較されます。 Claimedmtuはmaxsizeackedよりも小さい（フルサイズのパケットがリモートエンドポイントに到達していた）ため、このパケットはPath-MTU Updateを実行していると見なされ、「保留エラー」状態が記録されます。
In line 4, the segment times out. Thus, nsegrto is incremented by 1. As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path-MTU is updated. The nsegrto variable is reset to 0, maxsizeacked is set to claimedmtu, and maxsizesent is set to the minimum MTU of the Internet Protocol in use.
4行目で、セグメントがタイムアウトします。したがって、nsegrtoは1ずつ増加します。nsegrtoがMAXSEGRTO以上であるため、想定されるPath-MTUが更新されます。 nsegrto変数は0にリセットされ、maxsizeackedはClaimedmtuに設定され、maxsizesentは使用中のインターネットプロトコルの最小MTUに設定されます。
In line 5, H1 retransmits the data using the updated PMTU, and thus maxsizesent is set to 1492. The resulting packet reaches H2, where it elicits an acknowledgement (ACK) segment.
5行目で、H1は更新されたPMTUを使用してデータを再送信します。したがって、maxsizesentは1492に設定されます。結果のパケットはH2に到達し、確認応答（ACK）セグメントを引き出します。
In line 6, H1 finally gets the acknowledgement for the data segment. At this point, TCP has discovered the new Path-MTU for this TCP connection.
6行目で、H1は最終的にデータセグメントの確認応答を取得します。この時点で、TCPはこのTCP接続の新しいパスMTUを発見しました。
Let us suppose a TCP connection between H1 and H2 has already been established, and the PMTU for the connection has already been discovered to be 1500. Figure 4 shows a sample time-line diagram that illustrates an idle connection being attacked.
H1とH2の間のTCP接続がすでに確立されており、接続のPMTUがすでに1500であることが検出されていると仮定します。図4は、攻撃されているアイドル接続を示すサンプルのタイムライン図を示しています。
Host 1 Host 2
ホスト1ホスト2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> -->
2. <-- <SEQ=X><ACK=150><CTL=ACK> <--
3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
Figure 4: Idle Connection Being Attacked
図4：攻撃されているアイドル接続
In line 1, H1 sends its last bunch of data. In line 2, H2 acknowledges the receipt of these data. Then the connection becomes idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet Too Big" error messages to H1. Regardless of how many packets it sends and of the TCP sequence number each ICMP packet includes, none of these ICMP error messages will pass the TCP sequence number check described in Section 4.1, as H1 has no unacknowledged data "in flight" to H2. Therefore, the attack does not succeed.
1行目で、H1は最後のデータの束を送信します。 2行目で、H2はこれらのデータの受信を確認します。その後、接続はアイドルになります。 3、4、5行目で、攻撃者は偽造されたICMP "Packet Too Big"エラーメッセージをH1に送信します。送信するパケットの数と各ICMPパケットに含まれるTCPシーケンス番号に関係なく、これらのICMPエラーメッセージはセクション4.1で説明されているTCPシーケンス番号チェックに合格しません。したがって、攻撃は成功しません。
Let us suppose an attacker attacks a TCP connection for which the PMTU has already been discovered. In this case, as illustrated in Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a possible packet exchange.
攻撃者がPMTUがすでに発見されているTCP接続を攻撃するとします。この場合、図1に示すように、PMTUは1500バイトであることがわかります。図5は、可能なパケット交換を示しています。
Host 1 Host 2
ホスト1ホスト2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> -->
3. --> <SEQ=3020><ACK=X><CTL=ACK><DATA=1460> -->
4. --> <SEQ=4480><ACK=X><CTL=ACK><DATA=1460> -->
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
6. <-- <SEQ=X><CTL=ACK><ACK=1560> <--
Figure 5: Active Connection Being Attacked after Discovery of PMTU
図5：PMTUの検出後に攻撃されているアクティブな接続
As we assume the PMTU has already been discovered, we also assume both maxsizesent and maxsizeacked are equal to 1500. We assume nsegrto is equal to zero, as there have been no segment timeouts.
PMTUが既に検出されていると想定しているため、maxsizesentとmaxsizeackedの両方が1500に等しいと想定しています。セグメントのタイムアウトがなかったため、nsegrtoはゼロに等しいと想定しています。
In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 5, an attacker sends a forged ICMP error message to H1. We assume the attacker is lucky enough to guess both the four-tuple that identifies the connection and a valid TCP sequence number. As the Next-Hop MTU claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller than maxsizeacked, this packet is assumed to be performing Path-MTU Update. Thus, the error message is recorded.
1、2、3、および4行目で、H1は4つのデータセグメントをH2に送信します。 5行目で、攻撃者は偽造されたICMPエラーメッセージをH1に送信します。攻撃者は、接続を識別する4つのタプルと有効なTCPシーケンス番号の両方を推測できるほど幸運であると想定しています。 ICMPの「Packet Too Big」メッセージ（claimedmtu）で要求されているNext-Hop MTUがmaxsizeackedよりも小さいため、このパケットはPath-MTU更新を実行していると想定されます。したがって、エラーメッセージが記録されます。
In line 6, H1 receives an acknowledgement for the segment sent in line 1, before it times out. At this point, the "pending error" condition is cleared, and the recorded ICMP "Packet Too Big" error message is ignored. Therefore, the attack does not succeed.
6行目では、H1は1行目で送信されたセグメントの確認応答を受信してから、タイムアウトします。この時点で、「保留中のエラー」状態は解消され、記録されたICMP「パケットが大きすぎます」というエラーメッセージは無視されます。したがって、攻撃は成功しません。
7.3.5. TCP Peer Attacked when Sending Small Packets Just after the Three-Way Handshake
7.3.5. 3ウェイハンドシェイクの直後に小さなパケットを送信するとTCPピアが攻撃される
This section analyzes a scenario in which a TCP peer that is sending small segments just after the connection has been established is attacked. The connection could be in use by protocols such as SMTP [RFC5321] and HTTP [RFC2616], for example, which usually behave like this.
このセクションでは、接続が確立された直後に小さなセグメントを送信しているTCPピアが攻撃されるシナリオを分析します。接続は、SMTP [RFC5321]やHTTP [RFC2616]などのプロトコルによって使用されている可能性があり、通常はこのように動作します。
Figure 6 shows a possible packet exchange for such a scenario.
図6は、このようなシナリオで可能なパケット交換を示しています。
Host 1 Host 2
ホスト1ホスト2
1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=100> -->
5. <-- <SEQ=X+1><ACK=201><CTL=ACK> <--
6. --> <SEQ=201><ACK=X+1><CTL=ACK><DATA=100> -->
7. --> <SEQ=301><ACK=X+1><CTL=ACK><DATA=100> -->
8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=201 <---
Figure 6: TCP Peer Attacked when Sending Small Packets Just after the Three-Way Handshake
図6：3ウェイハンドシェイクの直後に小さなパケットを送信するとTCPピアが攻撃される
The nsegrto variable is initialized to zero. Both maxsizesent and maxsizeacked are initialized to the minimum MTU for the Internet Protocol being used (68 for IPv4, and 1280 for IPv6).
nsegrto変数はゼロに初期化されます。 maxsizesentとmaxsizeackedの両方が、使用されているインターネットプロトコルの最小MTU（IPv4の場合は68、IPv6の場合は1280）に初期化されます。
In lines 1 to 3, the three-way handshake takes place, and the connection is established. At this point, the assumed Path-MTU for this connection is 4464. In line 4, H1 sends a small segment (which results in a 140-byte packet) to H2. Therefore, maxsizesent is set to 140. In line 5, this segment is acknowledged, and thus maxsizeacked is set to 140.
1行目から3行目では、3ウェイハンドシェイクが行われ、接続が確立されます。この時点で、この接続の想定パスMTUは4464です。4行目で、H1は小さなセグメント（結果として140バイトのパケット）をH2に送信します。したがって、maxsizesentは140に設定されます。5行目で、このセグメントは確認応答され、maxsizeackedは140に設定されます。
In lines 6 and 7, H1 sends two small segments to H2. In line 8, while the segments from lines 6 and 7 are still "in flight" to H2, an attacker sends a forged ICMP "Packet Too Big" error message to H1. Assuming the attacker is lucky enough to guess a valid TCP sequence number, this ICMP message will pass the TCP sequence number check. The Next-Hop MTU reported by the ICMP error message (claimedmtu) is then compared with maxsizesent. As claimedmtu is larger than maxsizesent, the ICMP error message is silently discarded. Therefore, the attack does not succeed.
6行目と7行目で、H1は2つの小さなセグメントをH2に送信します。 8行目では、6行目と7行目からのセグメントがまだH2に「処理中」ですが、攻撃者は偽造されたICMP "Packet Too Big"エラーメッセージをH1に送信します。攻撃者が幸運で有効なTCPシーケンス番号を推測できると想定すると、このICMPメッセージはTCPシーケンス番号チェックに合格します。次に、ICMPエラーメッセージ（claimedmtu）によって報告されたネクストホップMTUがmaxsizesentと比較されます。 Claimedmtuがmaxsizesentよりも大きいため、ICMPエラーメッセージは通知なく破棄されます。したがって、攻撃は成功しません。
7.4. Pseudo-Code for the Counter-Measure for the Blind Performance-Degrading Attack
7.4. ブラインドパフォーマンス低下攻撃の対抗策の疑似コード
This section contains a pseudo-code version of the counter-measure described in Section 7.2 for the blind performance-degrading attack described in Section 7. It is meant as guidance for developers on how to implement this counter-measure.
このセクションには、セクション7.2で説明されている、セクション7で説明されているブラインドパフォーマンス低下攻撃に対するカウンターコードの疑似コードバージョンが含まれています。
The pseudo-code makes use of the following variables, constants, and functions: ack Variable holding the acknowledgement number contained in the TCP segment that has just been received.
疑似コードは、以下の変数、定数、および関数を使用します。ack受信されたばかりのTCPセグメントに含まれる確認番号を保持する変数。
acked_packet_size Variable holding the packet size (data, plus headers) that the ACK that has just been received is acknowledging.
acked_packet_size受信されたばかりのACKが確認応答しているパケットサイズ（データとヘッダー）を保持する変数。
adjust_mtu() Function that adjusts the MTU for this connection, according to the ICMP "Packet Too Big" that was last received.
adjust_mtu()最後に受信したICMP "Packet Too Big"に従って、この接続のMTUを調整する関数。
claimedmtu Variable holding the Next-Hop MTU advertised by the ICMP "Packet Too Big" error message.
ICMP "Packet Too Big"エラーメッセージによってアドバタイズされるネクストホップMTUを保持する
claimedtcpseq Variable holding the TCP sequence number contained in the payload of the ICMP "Packet Too Big" message that has just been received or was last recorded.
Claimscpseq ICMPの「Packet Too Big」メッセージのペイロードに含まれるTCPシーケンス番号を保持する変数。
current_mtu Variable holding the assumed Path-MTU for this connection.
current_mtuこの接続で想定されるパスMTUを保持する変数。
drop_message() Function that performs the necessary actions to drop the ICMP message being processed.
drop_message()処理中のICMPメッセージを削除するために必要なアクションを実行する関数。
initial_mtu Variable holding the MTU for new connections, as explained in [RFC1191] and [RFC1981].
[RFC1191]および[RFC1981]で説明されているように、新しい接続のMTUを保持する変数です。
maxsizeacked Variable holding the largest packet size (data, plus headers) that has so far been acked for this connection, as explained in Section 7.2.
セクション7.2で説明されているように、この接続でこれまでに確認応答された最大パケットサイズ（データとヘッダー）を保持する変数。
maxsizesent Variable holding the largest packet size (data, plus headers) that has so far been sent for this connection, as explained in Section 7.2.
maxsizesentセクション7.2で説明するように、この接続でこれまでに送信された最大パケットサイズ（データとヘッダー）を保持する変数。
nsegrto Variable holding the number of times this segment has timed out, as explained in Section 7.2.
セクション7.2で説明されているように、このセグメントがタイムアウトした回数を保持するnsegrto変数。
packet_size Variable holding the size of the IP datagram being sent.
packet_size送信されるIPデータグラムのサイズを保持する変数。
pending_message Variable (flag) that indicates whether there is a pending ICMP "Packet Too Big" message to be processed.
pending_message処理される保留中のICMP "Packet Too Big"メッセージがあるかどうかを示す変数（フラグ）。
save_message() Function that records the ICMP "Packet Too Big" message that has just been received.
save_message()受信したばかりのICMP "Packet Too Big"メッセージを記録する関数。
MINIMUM_MTU Constant holding the minimum MTU for the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
MINIMUM_MTU使用中のインターネットプロトコルの最小MTUを保持する定数（IPv4の場合は68、IPv6の場合は1280）。
MAXSEGRTO Constant holding the number of times a given segment must time out before an ICMP "Packet Too Big" error message can be honored.
MAXSEGRTO ICMPの「Packet Too Big」エラーメッセージが受け入れられる前に、特定のセグメントがタイムアウトしなければならない回数を保持する定数。
EVENT: New TCP connection
イベント：新しいTCP接続
current_mtu = initial_mtu;
maxsizesent = MINIMUM_MTU;
maxsizeacked = MINIMUM_MTU;
nsegrto = 0;
pending_message = 0;
EVENT: Segment is sent
イベント：セグメントが送信されます
if (packet_size > maxsizesent) maxsizesent = packet_size;
if（packet_size> maxsizesent）maxsizesent = packet_size;
EVENT: Segment is received
イベント：セグメントが受信されました
if (acked_packet_size > maxsizeacked) maxsizeacked = acked_packet_size;
if（acked_packet_size> maxsizeacked）maxsizeacked = acked_packet_size;
if (pending_message)
if (ack > claimedtcpseq){
pending_message = 0;
nsegrto = 0;
}
EVENT: ICMP "Packet Too Big" message is received
イベント：ICMP「Packet Too Big」メッセージを受信しました
if (claimedmtu <= MINIMUM_MTU)
drop_message();
if (claimedtcpseq < SND.UNA || claimedtcpseq >= SND.NXT)
drop_message();
else {
if (claimedmtu > maxsizesent || claimedmtu >= current_mtu)
drop_message();
else {
if (claimedmtu > maxsizeacked){
adjust_mtu();
current_mtu = claimedmtu;
maxsizesent = MINIMUM_MTU;
}
else {
pending_message = 1;
save_message();
}
}
}
EVENT: Segment times out
イベント：セグメントがタイムアウトしました
nsegrto++;
if (pending_message && nsegrto >= MAXSEGRTO){
adjust_mtu();
nsegrto = 0;
pending_message = 0;
maxsizeacked = claimedmtu;
maxsizesent = MINIMUM_MTU;
current_mtu = claimedmtu;
}
Notes: All comparisons between sequence numbers must be performed using sequence number arithmetic.
注：シーケンス番号間のすべての比較は、シーケンス番号演算を使用して実行する必要があります。
The pseudo-code implements the mechanism described in Section 7.2, the TCP sequence number checking described in Section 4.1, and the validation check on the advertised Next-Hop MTU described in [RFC1191] and [RFC1981].
疑似コードは、セクション7.2で説明されているメカニズム、セクション4.1で説明されているTCPシーケンス番号チェック、および[RFC1191]と[RFC1981]で説明されているアドバタイズされたネクストホップMTUの検証チェックを実装します。
This document describes the use of ICMP error messages to perform a number of attacks against TCP, and describes a number of widely implemented counter-measures that either eliminate or reduce the impact of these attacks when they are performed by off-path attackers.
このドキュメントでは、ICMPエラーメッセージを使用してTCPに対していくつかの攻撃を実行し、これらの攻撃がパス外の攻撃者によって実行された場合の影響を排除または軽減する、広く実装されている多くの対策について説明します。
Section 4.1 describes a validation check that could be enforced on ICMP error messages, such that TCP reacts only to those ICMP error messages that appear to relate to segments currently "in flight" to the destination system. This requires more effort on the side of an off-path attacker at the expense of possible reduced responsiveness to network errors.
セクション4.1では、ICMPエラーメッセージに適用できる検証チェックについて説明します。これにより、TCPは、宛先システムに現在「進行中」のセグメントに関連していると思われるICMPエラーメッセージにのみ反応します。これには、ネットワークエラーへの応答性が低下する可能性を犠牲にして、オフパス攻撃者の側でより多くの努力が必要です。
Section 4.2 describes how randomization of TCP ephemeral ports requires more effort on the side of the attacker to successfully exploit any of the attacks described in this document.
セクション4.2では、TCP一時ポートのランダム化で、このドキュメントで説明されている攻撃を悪用するために、攻撃者の側でより多くの労力が必要になる方法について説明します。
Section 4.3 describes how ICMP error messages could possibly be filtered based on their payload, to prevent users of the local network from successfully performing attacks against third-party connections. This is analogous to ingress filtering and egress filtering of IP packets [IP-filtering].
セクション4.3では、ローカルネットワークのユーザーがサードパーティの接続に対して攻撃を実行できないようにするために、ICMPエラーメッセージをペイロードに基づいてフィルタリングする方法について説明します。これは、IPパケットの入力フィルタリングと出力フィルタリングに類似しています[IP-filtering]。
Section 5.2 describes an attack-specific counter-measure for the blind connection-reset attack. It describes the processing of ICMP "hard errors" as "soft errors" when they are received for connections in any of the synchronized states. This counter-measure eliminates the aforementioned vulnerability in synchronized connections at the expense of possible reduced responsiveness in some network scenarios.
セクション5.2では、ブラインド接続リセット攻撃に対する攻撃固有の対策について説明します。 ICMPの「ハードエラー」の処理が、同期状態のいずれかの接続で受信された場合の「ソフトエラー」として説明されています。この対策により、一部のネットワークシナリオで応答性が低下する可能性を犠牲にして、同期接続の前述の脆弱性が排除されます。
Section 6.2 describes an attack-specific counter-measure for the blind throughput-reduction attack. It suggests that the aforementioned vulnerability can be eliminated by ignoring ICMPv4 Source Quench messages meant for TCP connections. This is in accordance with research results that indicate that ICMPv4 Source Quench messages are ineffective and are an unfair antidote for congestion.
6.2節では、ブラインドスループット削減攻撃に対する攻撃固有の対策について説明します。 TCP接続用のICMPv4 Source Quenchメッセージを無視することで、前述の脆弱性を排除できることを示唆しています。これは、ICMPv4 Source Quenchメッセージは効果がなく、輻輳の不当な解毒剤であることを示す調査結果と一致しています。
Finally, Section 7.2 describes an attack-specific counter-measure for the blind performance-degrading attack. It consists of the validation check described in Section 4.1, with a modification that makes TCP react to ICMP "Packet Too Big" error messages such that they are processed when an outstanding TCP segment times out. This counter-measure parallels the Packetization Layer Path MTU Discovery (PLPMTUD) mechanism [RFC4821]. It should be noted that if this counter-measure is implemented, in some scenarios TCP may respond more slowly to valid ICMP "Packet Too Big" error messages.
最後に、セクション7.2では、パフォーマンスを低下させるブラインド攻撃に対する攻撃固有の対策について説明します。これは、4.1節で説明した検証チェックで構成され、未処理のTCPセグメントがタイムアウトしたときに処理されるように、TCPがICMPの「パケットが大きすぎます」エラーメッセージに反応するように変更されています。この対抗策は、パケット化層パスMTU発見（PLPMTUD）メカニズム[RFC4821]に対応しています。この対策が実装されている場合、一部のシナリオでは、TCPが有効なICMP "Packet Too Big"エラーメッセージへの応答が遅くなることに注意してください。
A discussion of these and other attack vectors for performing similar attacks against TCP (along with possible counter-measures) can be found in [CPNI-TCP] and [TCP-SECURITY].
TCPに対して同様の攻撃を実行するためのこれらの攻撃ベクトルとその他の攻撃ベクトル（および可能な対策）については、[CPNI-TCP]および[TCP-SECURITY]で説明されています。
This document was inspired by Mika Liljeberg, while discussing some issues related to [RFC5461] by private e-mail. The author would like to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Lars Eggert, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, Matt Mathis, David Miller, Toby Moncaster, Miles Nordin, Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith, Pyda Srisuresh, Fred Templin, and Joe Touch for contributing many valuable comments.
このドキュメントは、[RFC5461]に関連するいくつかの問題についてプライベートメールで議論しながら、Mika Liljebergに触発されました。著者は（アルファベット順）に感謝します：ボラアキョル、マークオールマン、ランアトキンソン、ジェームスカールソン、アランコックス、テオデラート、ウェスリーエディ、ラースエガート、テッドファーバー、フアンフラスキーニ、マーカスフリードル、ギジェルモゴン、ジョンヘフナー、アルフレッドホーネス、ビベックカッカー、マイケルケリスク、ミカリリエベリ、マットマティス、デビッドミラー、トビーモンキャスター、マイルズノルディン、エロイパリ、カチョンプーン、アンドリューパウエル、ペッカサボラ、ドナルドスミス、ピダスリスレッシュ、フレッドテンプリン、ジョータッチ多くの貴重なコメントを提供してくれた。
Juan Fraschini and the author of this document implemented freely available audit tools to help vendors audit their systems by reproducing the attacks discussed in this document. These tools are available at http://www.gont.com.ar/tools/index.html.
Juan Fraschiniとこのドキュメントの作成者は、このドキュメントで説明されている攻撃を再現することでベンダーがシステムを監査できるように、無料で利用できる監査ツールを実装しました。これらのツールは、http：//www.gont.com.ar/tools/index.htmlから入手できます。
Markus Friedl, Chad Loder, and the author of this document produced and tested in OpenBSD [OpenBSD] the first implementation of the counter-measure described in Section 7.2. This first implementation helped to test the effectiveness of the ideas introduced in this document, and has served as a reference implementation for other operating systems.
Markus Friedl、Chad Loder、およびこのドキュメントの作成者は、セクション7.2で説明されている対策の最初の実装を作成し、OpenBSD [OpenBSD]でテストしました。この最初の実装は、このドキュメントで紹介したアイデアの有効性をテストするのに役立ち、他のオペレーティングシステムのリファレンス実装として機能しました。
The author would like to thank the UK's Centre for the Protection of National Infrastructure (CPNI) -- formerly the National Infrastructure Security Co-ordination Centre (NISCC) -- for coordinating the disclosure of these issues with a large number of vendors and CSIRTs (Computer Security Incident Response Teams).
著者は、これらの問題の開示を多数のベンダーやCSIRTと調整してくれたUKの国家インフラ保護センター（CPNI）（以前は国家インフラ安全保障調整センター（NISCC））に感謝します。 Computer Security Incident Response Teams）。
The author wishes to express deep and heartfelt gratitude to Jorge Oscar Gont and Nelida Garcia, for their precious motivation and guidance.
著者は、Jorge Oscar GontとNelida Garciaの貴重な動機とガイダンスに深く心からの感謝の意を表したいと思います。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、1996年8月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「拡張ICMPによるマルチパートメッセージのサポート」、RFC 4884、2007年4月。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", http://www.cpni.gov.uk/ Docs/tn-03-09-security-assessment-TCP.pdf, 2009.
[CPNI-TCP] CPNI、「TCP（Transmission Control Protocol）のセキュリティ評価」、http：//www.cpni.gov.uk/ Docs / tn-03-09-security-assessment-TCP.pdf、2009年。
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet Protocols", Computer Communication Review Vol. 18, No. 4, 1988.
[DClark]クラークD。、「DARPAインターネットプロトコルの設計哲学」、Computer Communication Review Vol。 18、No。4、1988。
[FreeBSD] The FreeBSD Project, http://www.freebsd.org.
[FreeBSD] FreeBSDプロジェクト、http：//www.freebsd.org。
[ICMP-Filtering] Gont, F., "Filtering of ICMP error messages", http ://www.gont.com.ar/papers/ filtering-of-icmp-error-messages.pdf.
[ICMP-フィルタリング] Gont、F。、「ICMPエラーメッセージのフィルタリング」、http：//www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf。
[IP-filtering] NISCC, "NISCC Technical Note 01/2006: Egress and Ingress Filtering", http://www.cpni.gov.uk/Docs/re-20060420-00294.pdf, 2006.
[IPフィルタリング] NISCC、「NISCC Technical Note 01/2006：Egress and Ingress Filtering」、http：//www.cpni.gov.uk/Docs/re-20060420-00294.pdf、2006。
[Linux] The Linux Project, "http://www.kernel.org".
[Linux] Linuxプロジェクト、「http://www.kernel.org」。
[McKusick] McKusick, M., Bostic, K., Karels, M., and J. Quarterman, "The Design and Implementation of the 4.4 BSD Operating System", Addison-Wesley, 1996.
[McKusick] McKusick、M.、Bostic、K.、Karels、M.、J. Quarterman、 "The Design and Implementation of the 4.4 BSD Operating System"、Addison-Wesley、1996。
[NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ ICMP: Vulnerability Issues in ICMP packets with TCP payloads", http://www.cpni.gov.uk/docs/ re-20050412-00303.pdf?lang=en, 2005.
[NISCC] NISCC、「NISCC Vulnerability Advisory 532967 / NISCC / ICMP：ICMPパケットとTCPペイロードの脆弱性の問題」、http：//www.cpni.gov.uk/docs/ re-20050412-00303.pdf？lang = en 、2005。
[NetBSD] The NetBSD Project, "http://www.netbsd.org".
[NetBSD] NetBSDプロジェクト、 "http://www.netbsd.org"。
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenBSD] OpenBSDプロジェクト、 "http://www.openbsd.org"。
[OpenBSD-PF] The OpenBSD Packet Filter, "http://www.openbsd.org/faq/pf/".
[OpenBSD-PF] OpenBSDパケットフィルター、「http://www.openbsd.org/faq/pf/」。
[PORT-RANDOM] Larsen, M. and F. Gont, "Transport Protocol Port Randomization Recommendations", Work in Progress, April 2010.
[PORT-RANDOM] Larsen、M。およびF. Gont、「Transport Protocol Port Randomization Recommendations」、Work in Progress、2010年4月。
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, July 1982.
[RFC0816]クラークD.、「障害の分離と回復」、RFC 816、1982年7月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[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 Extensions for High Performance」、RFC 1323、1992年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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryに関するTCPの問題」、RFC 2923、2000年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M。、フロイド、S。、およびC.パートリッジ、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[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月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC4907] Aboba, B., "Architectural Implications of Link Indications", RFC 4907, June 2007.
[RFC4907] Aboba、B。、「Link Indicationsのアーキテクチャ上の影響」、RFC 4907、2007年6月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953] Touch、J。、「なりすまし攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC 5461]フォント、OF。、「ソフトエラーに対するTCPの反応」、RFC 5461、2009年2月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[TCP-SECURITY] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, February 2010.
[TCP-SECURITY] Gont、F。、「Transmission Control Protocol（TCP）のセキュリティ評価」、Work in Progress、2010年2月。
[TCPM-TCPSECURE] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, May 2010.
[TCPM-TCPSECURE]ラマイア、A。、スチュワート、R。、およびM.ダラル、「ウィンドウ内のブラインド攻撃に対するTCPの堅牢性の向上」、2010年5月、作業中。
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP Implementations do not adequately validate ICMP error messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[US-CERT] US-CERT、「US-CERT脆弱性ノートVU＃222750：TCP / IP実装はICMPエラーメッセージを適切に検証しない」、http：//www.kb.cert.org/vuls/id/222750、 2005年
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest Conference, 2004.
[ワトソン]ワトソン、P。、「ウィンドウのスリップ：TCPリセット攻撃」、CanSecWest会議、2004年。
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1994.
[ライト]ライト、G、およびW.スティーブンス、「TCP / IP Illustrated、Volume 2：The Implementation」、Addison-Wesley、1994。
Author's Address
著者のアドレス
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンドゴン国立工科大学/ Haedo Evaristo Carriego Regional College 2644ブエノスアイレス州ハエド1706アルゼンチン
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar