[要約] 要約：RFC 4963は、高データレートでのIPv4再構築エラーに関する情報を提供するものです。 目的：このRFCの目的は、高データレート環境でのIPv4再構築エラーの理解と対策を促進することです。
Network Working Group J. Heffner
Request for Comments: 4963 M. Mathis
Category: Informational B. Chandler
PSC
July 2007
IPv4 Reassembly Errors at High Data Rates
IPv4は、高いデータレートでエラーを再組み立てします
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations.
IPv4の断片化は、今日のインターネットの一部の条件下で使用するのに十分に堅牢ではありません。高いデータレートでは、16ビットIP識別フィールドは、頻繁に誤って組み立てられたIPフラグメントを防ぐのに十分な大きさではなく、TCPおよびUDPチェックサムは、結果として生じる破損したデータグラムがより高いプロトコル層に配信されるのを防ぐために不十分です。このメモは、問題を実証する簡単に再現されたいくつかの実験について説明し、これらの観察の運用上の意味のいくつかについて説明します。
The IPv4 header was designed at a time when data rates were several orders of magnitude lower than those achievable today. This document describes a consequent scale-related failure in the IP identification (ID) field, where fragments may be incorrectly assembled at a rate high enough that it is likely to invalidate assumptions about data integrity failure rates.
IPv4ヘッダーは、現在達成可能なデータレートよりも数桁低いときに設計されました。このドキュメントでは、IP識別（ID）フィールドでのスケール関連の障害について説明します。ここでは、データの整合性障害率に関する仮定を無効にする可能性が高いため、フラグメントが十分に高いレートで誤って組み立てられる可能性があります。
That IP fragmentation results in inefficient use of the network has been well documented [Kent87]. This note presents a different kind of problem, which can result not only in significant performance degradation, but also frequent data corruption. This is especially pertinent due to the recent proliferation of UDP bulk transport tools that sometimes fragment every datagram.
そのIP断片化により、ネットワークの非効率的な使用が得られていることが十分に文書化されています[Kent87]。このメモは、異なる種類の問題を提示します。これは、パフォーマンスの大幅な劣化だけでなく、頻繁なデータの腐敗にも発生する可能性があります。これは、すべてのデータグラムを断片化することがあるUDPバルク輸送ツールの最近の拡散により、特に適切です。
Additionally, there is some network equipment that ignores the Don't Fragment (DF) bit in the IP header to work around MTU discovery problems [RFC2923]. This equipment indirectly exposes properly implemented protocols and applications to corrupt data.
さらに、MTU発見の問題[RFC2923]を回避するために、IPヘッダーの断片（DF）ビットを無視するネットワーク機器がいくつかあります。この機器は、適切に実装されたプロトコルとアプリケーションを破損したデータに間接的に公開します。
The Internet Protocol standard [RFC0791] specifies:
インターネットプロトコル標準[RFC0791]が指定します。
"The choice of the Identifier for a datagram is based on the need to provide a way to uniquely identify the fragments of a particular datagram. The protocol module assembling fragments judges fragments to belong to the same datagram if they have the same source, destination, protocol, and Identifier. Thus, the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the Internet."
「データグラムの識別子の選択は、特定のデータグラムのフラグメントを一意に識別する方法を提供する必要性に基づいています。プロトコルモジュールは、同じソース、宛先、宛先がある場合、同じデータグラムに属するフラグメントを断片的に組み立てるプロトコルモジュールを組み立てます。したがって、プロトコル、および識別子。したがって、送信者は、データグラム（またはその断片）がインターネットで生きている可能性があるため、このソース、宛先ペア、およびプロトコルに一意になるように識別子を選択する必要があります。」
Strict conformance to this standard limits transmissions in one direction between any address pair to no more than 65536 packets per protocol (e.g., TCP, UDP, or ICMP) per maximum packet lifetime.
この標準への厳格な適合性は、アドレスペア間の一方向の送信を、プロトコルごとに65536パケット（例：TCP、UDP、またはICMPなど）を最大パケット寿命ごとに制限します。
Clearly, not all hosts follow this standard because it implies an unreasonably low maximum data rate. For example, a host sending 1500-byte packets with a 30-second maximum packet lifetime could send at only about 26 Mbps before exceeding 65535 packets per packet lifetime. Or, filling a 1 Gbps interface with 1500-byte packets requires sending 65536 packets in less than 1 second, an unreasonably short maximum packet lifetime, being less than the round-trip time on some paths. This requirement is widely ignored.
明らかに、すべてのホストがこの標準に従うわけではありません。なぜなら、それは不当に低い最大データレートを意味するためです。たとえば、30秒の最大パケット寿命で1500バイトのパケットを送信するホストは、パケット寿命あたり65535パケットを超える前に、約26 Mbpsでわずか26 Mbpsで送信できます。または、1500バイトのパケットで1 Gbpsインターフェイスを入力するには、1秒未満で65536パケットを送信する必要があります。この要件は広く無視されています。
Additionally, it is worth noting that reusing values in the IP ID field once per 65536 datagrams is the best case. Some implementations randomize the IP ID to prevent leaking information out of the kernel [Bellovin02], which causes reuse of the IP ID field to occur probabilistically at all sending rates.
さらに、65536データグラムごとに1回のIDフィールドで値を再利用することが最良のケースであることに注意する価値があります。いくつかの実装は、IP IDをランダム化して、カーネル[Bellovin02]から情報の漏れを防ぐために、IP IDフィールドの再利用により、すべての送信率で確率的に発生します。
IP receivers store fragments in a reassembly buffer until all fragments in a datagram arrive, or until the reassembly timeout expires (15 seconds is suggested in [RFC0791]). Fragments in a datagram are associated with each other by their protocol number, the value in their ID field, and by the source/destination address pair. If a sender wraps the ID field in less than the reassembly timeout, it becomes possible for fragments from different datagrams to be incorrectly spliced together ("mis-associated"), and delivered to the upper layer protocol.
IPレシーバーは、データグラム内のすべてのフラグメントが到着するまで、または再組み立てタイムアウトの有効期限が切れるまで、再組み立てバッファにフラグメントを保存します（[RFC0791]で15秒が提案されています）。データグラムのフラグメントは、プロトコル番号、IDフィールドの値、およびソース/宛先アドレスペアによって互いに関連付けられています。送信者がIDフィールドを再組み立てタイムアウトよりも少ない場合にラップすると、異なるデータグラムのフラグメントが誤ってスプライスされ（「誤った関連」）、上層のプロトコルに配信されることが可能になります。
A case of particular concern is when mis-association is self-propagating. This occurs, for example, when there is reliable ordering of packets and the first fragment of a datagram is lost in the network. The rest of the fragments are stored in the fragment reassembly buffer, and when the sender wraps the ID field, the first fragment of the new datagram will be mis-associated with the rest of the old datagram. The new datagram will be now be incomplete (since it is missing its first fragment), so the rest of it will be saved in the fragment reassembly buffer, forming a cycle that repeats every 65536 datagrams. It is possible to have a number of simultaneous cycles, bounded by the size of the fragment reassembly buffer.
特に懸念される場合は、誤った関連付けが自己伝播している場合です。これは、たとえば、パケットの信頼できる順序があり、データグラムの最初のフラグメントがネットワークで失われた場合に発生します。残りのフラグメントはフラグメント再組み立てバッファーに保存され、送信者がIDフィールドをラップすると、新しいデータグラムの最初のフラグメントは、古いデータグラムの残りの部分と誤って関連付けられます。新しいデータグラムは不完全になり（最初のフラグメントが欠落しているため）、残りはフラグメント再組み立てバッファに保存され、65536のデータグラムを繰り返すサイクルを形成します。フラグメントの再組み立てバッファーのサイズに囲まれた多くの同時サイクルを持つことができます。
IPv6 is considerably less vulnerable to this type of problem, since its fragment header contains a 32-bit identification field [RFC2460]. Mis-association will only be a problem at packet rates 65536 times higher than for IPv4.
IPv6は、このタイプの問題に対してかなり脆弱ではありません。そのフラグメントヘッダーには32ビット識別フィールド[RFC2460]が含まれているためです。誤解は、IPv4の場合よりも65536倍のパケットレートでのみ問題になります。
When the mis-associated fragments are delivered, transport-layer checksumming should detect these datagrams as incorrect and discard them. When the datagrams are discarded, it could create a performance problem for loss-feedback congestion control algorithms, particularly when a large congestion window is required, since it will introduce a certain amount of non-congestive loss.
誤った関連のフラグメントが配信されると、輸送層のチェックサムは、これらのデータグラムを正しくないように検出して破棄する必要があります。データグラムが破棄されると、特に大きな渋滞ウィンドウが必要な場合は、一定量の非同義の損失が導入されるため、損失フィードバックの混雑制御アルゴリズムのパフォーマンス問題を作成する可能性があります。
Transport checksums, however, may not be designed to handle such high error rates. The TCP/UDP checksum is only 16 bits in length. If these checksums follow a uniform random distribution, we expect mis-associated datagrams to be accepted by the checksum at a rate of one per 65536. With only one mis-association cycle, we expect corrupt data delivered to the application layer once per 2^32 datagrams.
ただし、輸送チェックサムは、このような高いエラー率を処理するように設計されていない場合があります。TCP/UDPチェックサムの長さはわずか16ビットです。これらのチェックサムが均一なランダム分布に従う場合、誤った関連データグラムは65536に1つのレートでチェックサムによって受け入れられると予想します。1つの誤協会サイクルのみで、2^あたり1回アプリケーション層に配信される破損したデータが提供されると予想されます。32のデータグラム。
This number can be significantly higher with multiple concurrent cycles.
この数値は、複数の同時サイクルで大幅に高くなる可能性があります。
With non-random data, the TCP/UDP checksum may be even weaker still. It is possible to construct datasets where mis-associated fragments will always have the same checksum. Such a case may be considered unlikely, but is worth considering. "Real" data may be more likely than random data to cause checksum hot spots and increase the probability of false checksum match [Stone98]. Also, some applications or higher-level protocols may turn off checksumming to increase speed, though this practice has been found to be dangerous for other reasons when data reliability is important [Stone00].
非ランダムデータを使用すると、TCP/UDPチェックサムはさらに弱くなる可能性があります。誤関連のフラグメントが常に同じチェックサムを持つデータセットを構築することが可能です。このような場合は、考えられる可能性は低いかもしれませんが、検討する価値があります。「実際の」データは、ランダムデータよりもチェックサムのホットスポットを引き起こし、誤ったチェックサムマッチの確率を高める可能性があります[Stone98]。また、一部のアプリケーションまたは高レベルのプロトコルはチェックサムをオフにして速度を上げる可能性がありますが、データの信頼性が重要である他の理由でこのプラクティスは危険であることがわかっています[Stone00]。
To test the practical impact of fragmentation on UDP, we ran a series of experiments using a UDP bulk data transport protocol that was designed to be used as an alternative to TCP for transporting large data sets over specialized networks. The tool, Reliable Blast UDP (RBUDP), part of the QUANTA networking toolkit [QUANTA], was selected because it has a clean interface which facilitated automated experiments. The decision to use RBUDP had little to do with the details of the transport protocol itself. Any UDP transport protocol that does not have additional means to detect corruption, and that could be configured to use IP fragmentation, would have the same results.
UDPに対する断片化の実際的な影響をテストするために、特殊なネットワークを介して大規模なデータセットを輸送するためのTCPの代替として使用するように設計されたUDPバルクデータ輸送プロトコルを使用して、一連の実験を実行しました。Quanta Networking Toolkit [Quanta]の一部である信頼できるBlast UDP（RBUDP）は、自動化された実験を促進するクリーンなインターフェイスを備えているために選択されました。RBUDPを使用するという決定は、輸送プロトコル自体の詳細とはほとんど関係ありませんでした。腐敗を検出するための追加の手段がなく、IPフラグメンテーションを使用するように構成できるUDP輸送プロトコルは、同じ結果をもたらします。
In order to diagnose corruption on files transferred with the UDP bulk transfer tool, we used a file format that included embedded sequence numbers and MD5 checksums in each fragment of each datagram. Thus, it was possible to distinguish random corruption from that caused by mis-associated fragments. We used two different types of files. One was constructed so that all the UDP checksums were constant -- we will call this the "constant" dataset. The other was constructed so that UDP checksums were uniformly random -- the "random" dataset. All tests were done using 400 MB files, sent in 1524-byte datagrams so that they were fragmented on standard Fast Ethernet with a 1500-byte MTU.
UDPバルク転送ツールで転送されたファイルの破損を診断するために、各データグラムの各フラグメントに埋め込まれたシーケンス番号とMD5チェックサムを含むファイル形式を使用しました。したがって、ランダムな腐敗を誤って関連する断片によって引き起こされるものと区別することが可能でした。2つの異なるタイプのファイルを使用しました。すべてのUDPチェックサムが一定になるように構築されました - これを「定数」データセットと呼びます。もう1つは、UDPチェックサムが均一にランダムになるように構築されました - 「ランダム」データセット。すべてのテストは、1524バイトのデータグラムで送信された400 MBファイルを使用して行われ、1500バイトのMTUで標準の高速イーサネットで断片化されました。
The UDP bulk file transport tool was used to send the datasets between a pair of hosts at slightly less than the available data rate (100 Mbps). Near the beginning of each flow, a brief secondary flow was started to induce packet loss in the primary flow. Throughout the life of the primary flow, we typically observed mis-association rates on the order of a few hundredths of a percent.
UDPバルクファイルトランスポートツールを使用して、利用可能なデータレート（100 Mbps）よりわずかに少ないホストのペア間でデータセットを送信しました。各流れの始まり近くで、一次流れのパケット損失を誘導するために、短い二次流が開始されました。主要な流れの生涯を通じて、私たちは通常、数百分の1パーセントの順序で誤解率を観察しました。
Tests run with the "constant" dataset resulted in corruption on all mis-associated fragments, that is, corruption on the order of a few hundredths of a percent. In sending approximately 10 TB of "random" datasets, we observed 8847668 UDP checksum errors and 121 corruptions of the data due to mis-associated fragments.
「一定の」データセットで実行されるテストは、すべての誤った関連する断片、つまり数百分の1パーセントの順序での腐敗に腐敗をもたらしました。約10 TBの「ランダム」データセットを送信する際に、8847668のUDPチェックサムエラーと、誤った関連のフラグメントによるデータの121の破損が観察されました。
The most straightforward way to avoid mis-association is to avoid fragmentation altogether by implementing Path MTU Discovery [RFC1191] [RFC4821]. However, this is not always feasible for all applications. Further, as a work-around for MTU discovery problems [RFC2923], some TCP implementations and communications gear provide mechanisms to disable path MTU discovery by clearing or ignoring the DF bit. Doing so will expose all protocols using IPv4, even those that participate in MTU discovery, to mis-association errors.
誤解を避けるための最も簡単な方法は、PATH MTU発見[RFC1191] [RFC4821]を実装することにより、断片化を完全に回避することです。ただし、これはすべてのアプリケーションで常に実行可能ではありません。さらに、MTU発見の問題[RFC2923]のワークアラウンドとして、一部のTCP実装と通信ギアは、DFビットをクリアまたは無視することにより、PATH MTU発見を無効にするメカニズムを提供します。そうすることで、MTU発見に参加するIPv4を使用してすべてのプロトコルを誤解エラーに公開します。
If IP fragmentation is in use, it may be possible to reduce the timeout sufficiently so that mis-association will not occur. However, there are a number of difficulties with such an approach. Since the sender controls the rate of packets sent and the selection of IP ID, while the receiver controls the reassembly timeout, there would need to be some mutual assurance between each party as to participation in the scheme. Further, it is not generally possible to set the timeout low enough so that a fast sender's fragments will not be mis-associated, yet high enough so that a slow sender's fragments will not be unconditionally discarded before it is possible to reassemble them. Therefore, the timeout and IP ID selection would need to be done on a per-peer basis. Also, it is likely NAT will break any per-peer tables keyed by IP address. It is not within the scope of this document to recommend solutions to these problems, though we believe a per-peer adaptive timeout is likely to prevent mis-association under circumstances where it would most commonly occur.
IPの断片化が使用されている場合、誤協会が発生しないようにタイムアウトを十分に削減できる可能性があります。ただし、このようなアプローチには多くの困難があります。送信者は送信されたパケットのレートとIP IDの選択を制御するため、受信者は再組み立てタイムアウトを制御しますが、スキームへの参加に関しては、各当事者間に相互保証が必要です。さらに、速い送信者のフラグメントが誤って関連付けられないようにしているので、タイムアウトを十分に低く設定することは一般に不可能ですが、遅い送信者のフラグメントがそれらを再組み立てる前に無条件に破棄されないようにします。したがって、タイムアウトとIP IDの選択は、ピアごとに行う必要があります。また、NATはIPアドレスでキーを入れたピアごとのテーブルを破壊する可能性があります。これらの問題の解決策を推奨するのはこのドキュメントの範囲内ではありませんが、ピアごとの適応タイムアウトは、最も一般的に発生する状況下で誤解を防ぐ可能性が高いと考えています。
A case particularly worth noting is that of tunnels encapsulating payload in IPv4. To deal with difficulties in MTU Discovery [RFC4459], tunnels may rely on fragmentation between the two endpoints, even if the payload is marked with a DF bit [RFC4301]. In such a mode, the two tunnel endpoints behave as IP end hosts, with all tunneled traffic having the same protocol type. Thus, the aggregate rate of tunneled packets may not exceed 65536 per maximum packet lifetime, or tunneled data becomes exposed to possible mis-association. Even protocols doing MTU discovery such as TCP will be affected. Operators of tunnels should ensure that the receiving end's reassembly timeout is short enough that mis-association cannot occur given the tunnel's maximum rate.
特に注目に値する場合は、IPv4のペイロードをカプセル化するトンネルのケースです。MTU発見[RFC4459]の困難に対処するために、トンネルは、ペイロードにDFビット[RFC4301]がマークされていても、2つのエンドポイント間の断片化に依存する場合があります。このようなモードでは、2つのトンネルエンドポイントがIPエンドホストとして動作し、すべてのトンネルトラフィックが同じプロトコルタイプを持っています。したがって、トンネルパケットの総速度は、最大パケット寿命ごとに65536を超えない場合があります。トンネルデータは、誤った誤用の可能性にさらされます。TCPなどのMTU発見を行うプロトコルでさえ影響を受けます。トンネルのオペレーターは、トンネルの最大速度を考慮して、誤協会が発生できないため、受信側の再組み立てタイムアウトが十分に短くなるようにする必要があります。
It is difficult to concisely describe all possible situations under which fragments might be mis-associated. Even if an end host carefully follows the specification, ensuring unique IP IDs, the presence of NATs or tunnels may expose applications to IP ID space conflicts. Further, devices in the network that the end hosts cannot see or control, such as tunnels, may cause mis-association. Even a fragmenting application that sends at a low rate might possibly be exposed when running simultaneously with a non-fragmenting application that sends at a high rate. As described above, the receiver might implement to reduce or eliminate the possibility of conflict, but there is no mechanism in place for a sender to know what the receiver is doing in this respect. As a consequence, there is no general mechanism for an application that is using IPv4 fragmentation to know if it is deterministically or statistically protected from mis-associated fragments.
フラグメントが誤って関連付けられる可能性のあるすべての可能な状況を簡潔に説明することは困難です。エンドホストが仕様に注意深く従っていても、一意のIP IDを確保する場合、NATまたはトンネルの存在がアプリケーションをIP IDスペースの競合に公開する可能性があります。さらに、エンドホストがトンネルなどの[最終ホストも把握または制御できないデバイスは、誤協会を引き起こす可能性があります。低速度で送信する断片化アプリケーションでさえ、高いレートで送信する非フラグメントアプリケーションと同時に実行するときに暴露される可能性があります。上記のように、受信者は紛争の可能性を減らすか排除するために実装するかもしれませんが、送信者がこの点で受信機が何をしているかを知るメカニズムはありません。結果として、IPv4フラグメンテーションを使用して、誤った関連の断片から決定論的または統計的に保護されているかどうかを知るアプリケーションの一般的なメカニズムはありません。
Under circumstances when it is impossible or impractical to prevent mis-association, its effects may be mitigated by use of stronger integrity checking at any layer above IP. This is a natural side effect of using cryptographic authentication. For example, IPsec AH [RFC4302] will discard any corrupted datagrams, preventing their deliver to upper layers. A stronger transport layer checksum such as SCTP's, which is 32 bits in length [RFC2960], may help significantly. At the application layer, SSH message authentication codes [RFC4251] will prevent delivery of corrupted data, though since the TCP connection underneath is not protected, it is considered invalid and the session is immediately terminated. While stronger integrity checking may prevent data corruption, it will not prevent the potential performance impact described above of non-congestive loss on congestion control at high congestion windows.
誤解を防ぐことが不可能または非現実的である状況下では、IPの上の任意の層でより強力な整合性チェックを使用することにより、その効果が軽減される場合があります。これは、暗号化認証を使用する自然な副作用です。たとえば、IPSEC AH [RFC4302]は、破損したデータグラムを破棄し、上層層への配信を防ぎます。長さ32ビット[RFC2960]であるSCTPなどのより強力な輸送層チェックサムは、大幅に役立つ可能性があります。アプリケーションレイヤーでは、SSHメッセージ認証コード[RFC4251]は破損したデータの提供を防ぎますが、下のTCP接続は保護されていないため、無効と見なされ、セッションはすぐに終了します。より強力な整合性チェックはデータの腐敗を防ぐ可能性がありますが、高渋滞ウィンドウでの混雑制御に対する非同時損失の上記の潜在的なパフォーマンスの影響を防ぐことはできません。
It should also be noted that mis-association is not the only possible source of data corruption above the network layer [Stone00]. Most applications for which data integrity is critically important should implement strong integrity checking regardless of exposure to mis-association.
また、ネットワークレイヤー[Stone00]の上にあるデータ腐敗の唯一の可能なソースではないことにも注意する必要があります。データの整合性が非常に重要であるほとんどのアプリケーションは、誤協会への暴露に関係なく、強力な完全性チェックを実装する必要があります。
In general, applications that rely on IPv4 fragmentation should be written with these issues in mind, as well as those issues documented in [Kent87]. Applications that rely on IPv4 fragmentation while sending at high speeds (the order of 100 Mbps or higher) and devices that deliberately introduce fragmentation to otherwise unfragmented traffic (e.g., tunnels) should be particularly cautious, and introduce strong mechanisms to ensure data integrity.
一般に、IPv4の断片化に依存するアプリケーションは、これらの問題を念頭に置いて記述する必要があります。また、[Kent87]に文書化された問題です。高速で送信しながらIPv4の断片化に依存するアプリケーション（100 Mbps以上）と、断片化を意図的に断片化するデバイス（例えば、トンネルなど）は特に慎重であり、データの整合性を確保するための強力なメカニズムを導入する必要があります。
If a malicious entity knows that a pair of hosts are communicating using a fragmented stream, it may be presented with an opportunity to corrupt the flow. By sending "high" fragments (those with offset greater than zero) with a forged source address, the attacker can deliberately cause corruption as described above. Exploiting this vulnerability requires only knowledge of the source and destination addresses of the flow, its protocol number, and fragment boundaries. It does not require knowledge of port or sequence numbers.
悪意のあるエンティティが、一対のホストが断片化されたストリームを使用して通信していることを知っている場合、流れを破壊する機会が提示される可能性があります。鍛造ソースアドレスを使用して「ハイ」フラグメント（ゼロを超えるオフセットのあるもの）を送信することにより、攻撃者は上記のように故意に腐敗を引き起こす可能性があります。この脆弱性を活用するには、フローのソースアドレスと宛先アドレス、そのプロトコル数、およびフラグメント境界に関する知識のみが必要です。ポート番号やシーケンス番号の知識は必要ありません。
If the attacker has visibility of packets on the path, the attack profile is similar to injecting full segments. Using this attack makes blind disruptions easier and might possibly be used to cause degradation of service. We believe only streams using IPv4 fragmentation are likely vulnerable. Because of the nature of the problems outlined in this document, the use of IPv4 fragmentation for critical applications may not be advisable, regardless of security concerns.
攻撃者がパス上のパケットの可視性を持っている場合、攻撃プロファイルは完全なセグメントを注入することに似ています。この攻撃を使用すると、盲目的な混乱が容易になり、サービスの劣化を引き起こすために使用される可能性があります。IPv4フラグメンテーションを使用したストリームのみが脆弱であると考えています。このドキュメントで概説されている問題の性質上、セキュリティの懸念に関係なく、重要なアプリケーションにIPv4断片化を使用することはお勧めできない場合があります。
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October 1987.
[Kent87] Kent、C。およびJ. Mogul、「断片化は有害と考えられている」、Proc。Sigcomm '87 Vol。17、No。5、1987年10月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[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月。
[Stone98] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, "Performance of Checksums and CRC's over Real Data", IEEE/ ACM Transactions on Networking vol. 6, No. 5, October 1998.
[Stone98] Stone、J.、Greenwald、M.、Partridge、C。、およびJ. Hughes、「チェックサムのパフォーマンスとCRCの実際のデータ」、IEEE/ ACMトランザクションNetworking Vol。6、No。5、1998年10月。
[Stone00] Stone, J. and C. Partridge, "When The CRC and TCP Checksum Disagree", Proc. SIGCOMM 2000 vol. 30, No. 4, October 2000.
[Stone00] Stone、J。およびC. Partridge、「CRCとTCPチェックサムが同意しないとき」、Proc。Sigcomm 2000 Vol。30、No。4、2000年10月。
[QUANTA] He, E., Alimohideen, J., Eliason, J., Krishnaprasad, N., Leigh, J., Yu, O., and T. DeFanti, "Quanta: a toolkit for high performance data delivery over photonic networks", Future Generation Computer Systems Vol. 19, No. 6, August 2003.
[Quanta] He、E.、Alimohideen、J.、Eliason、J.、Krishnaprasad、N.、Leigh、J.、Yu、O。、およびT. Defanti、 "Quanta：Photonic上の高性能データ配信のツールキットネットワーク」、Future Generation Computer Systems vol。19、No。6、2003年8月。
[Bellovin02] Bellovin, S., "A Technique for Counting NATted Hosts", Internet Measurement Conference, Proceedings of the 2nd ACM SIGCOMM Workshop on Internet Measurement, November 2002.
[Bellovin02] Bellovin、S。、「Natted Hostsをカウントするための手法」、インターネット測定会議、2002年11月、インターネット測定に関する第2 ACM Sigcommワークショップの議事録。
[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月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459] Savola、P。、「ネットワーク内トンネルに関するMTUおよび断片化の問題」、RFC 4459、2006年4月。
[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月。
This work was supported by the National Science Foundation under Grant No. 0083285.
この作業は、Grant No. 0083285の下で国立科学財団によってサポートされていました。
Authors' Addresses
著者のアドレス
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
ジョン・W・ヘフナー・ピッツバーグ・スーパーコンピューティング・センター4400フィフス・アベニュー・ピッツバーグ、ペンシルバニア州15213米国
Phone: 412-268-2329 EMail: jheffner@psc.edu
電話：412-268-2329メール：jheffner@psc.edu
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
マットマティスピッツバーグスーパーコンピューティングセンター4400フィフスアベニューピッツバーグ、ペンシルバニア州15213米国
Phone: 412-268-3319 EMail: mathis@psc.edu
電話：412-268-3319メール：mathis@psc.edu
Ben Chandler Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
ベンチャンドラーピッツバーグスーパーコンピューティングセンター4400フィフスアベニューピッツバーグ、ペンシルバニア州15213米国
Phone: 412-268-9783 EMail: bchandle@gmail.com
電話：412-268-9783メール：bchandle@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。