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
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）IETFトラスト（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ヘッダーのDo not Fragment（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.
最大パケット存続時間当たりのプロトコル（例えば、TCP、UDP、またはICMP）当たりせいぜい65536のパケットに任意のアドレスのペアの間に1つの方向に、この規格の制限の送信に厳密に準拠。
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で送信することができます。あるいは、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グラムあたりのIP 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受信機ストア断片まで（15秒[RFC0791]で提案されています）。データグラム内のフラグメントは、それらのプロトコル番号、それらの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.
そのフラグメントヘッダは、32ビットの識別フィールド[RFC2460]を含むのでIPv6は、かなりこの種の問題に対してより脆弱です。誤関連は、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回の割合でチェックサムによって受け入れられることを期待し、我々は、一度2 ^当たりのアプリケーション層に送ら破損データを期待します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バルクデータ転送プロトコルを使用して一連の実験を実行しました。それは自動化された実験を容易にしたクリーンなインターフェイスを持っているので、ツール、信頼性の高いブラストUDP（RBUDP）、QUANTA・ネットワーキング・ツールキット[QUANTA]の部分は、選択されました。 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チェックサムが一定であったように、一つは、構築しました。 「ランダム」データセット - UDPチェックサムは一様にランダムたように、他を構築しました。すべてのテストは、彼らが1500バイトのMTUと標準ファーストイーサネット上で断片化されたように、1524バイトのデータグラムで送信された400メガバイトのファイルを、使用して行きました。
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バルクファイル転送ツールは、利用可能なデータレート（100Mbpsの）よりもわずかに小さいでホストのペア間のデータセットを送信するために使用しました。各フローの先頭付近に、簡単な二次流れが主流で、パケットロスを誘発するために開始されました。主流の生活を通して、私たちは通常、パーセントの数百分の程度の誤会合速度を観察しました。
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.
テストは、すべてのミスに関連する断片に破損が生じ、それは、パーセントの数百分の程度の破損である「定数」データセットで実行されます。 「ランダム」データセットの約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.
誤関連付けを回避するための最も簡単な方法は、パスMTUディスカバリー[RFC1191] [RFC4821]を実装することにより、完全に断片化を避けるためです。しかし、これは常に、すべてのアプリケーションのための現実的ではありません。さらに、ワークアラウンドMTUディスカバリ問題[RFC2923]と同様に、いくつかのTCP実装と通信ギアDFビットをクリアするか、無視することによって、パス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のようなより強力なトランスポート層チェックサムは、大幅に助けることができます。 TCP接続が下に保護されていないので、それは無効とみなされ、セッションが直ちに終了されるがアプリケーション層で、SSHメッセージ認証コード[RFC4251]は、破損データの配信を防止します。強い整合性チェックはデータの破損を防ぐかもしれないが、それは高い輻輳ウィンドウでの輻輳制御上の非うっ血性損失の上述の潜在的なパフォーマンスへの影響を防ぐことはできません。
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]で文書それらの問題を記述する必要があります。高速で意図的にそうでない場合は断片化されていないトラフィック（例えば、トンネル）は、特に慎重でなければならないために断片を導入し、データの整合性を保証するために、強力なメカニズムを導入し、装置（100 Mbpsまたはそれ以上のオーダー）を送信しながら、IPv4の断片化に依存するアプリケーション。
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]ケント、C.及びJ.モーグルは、PROC、 "断片化は、有害と考え"。 SIGCOMM '87巻。 17、第5号、1987年10月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、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]ストーン、J.、グリーンワルド、M.、ヤマウズラ、C.、およびJ.ヒューズ、ネットワークの巻上、IEEE / ACMトランザクション "実データオーバーチェックサムとCRCののパフォーマンス"。 6、第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]石、J.およびC.ヤマウズラ、 "CRCとTCPチェックサムが同意しない"、PROC。 SIGCOMM 2000巻。 30、第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]彼、E.、Alimohideen、J.、Eliason、J.、Krishnaprasad、N.、リー、J.、ゆう、O.、およびT. DeFanti、「クアンタ：フォトニックにわたって高性能データ配信のためのツールキットネットワーク」、未来の世代コンピュータシステムズ集。 19、第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ホストをカウントするための技術」、インターネット測定コンファレンス、インターネット計測、2002年11月に第2回ACM SIGCOMMワークショップの議事。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、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、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]、RFC 4459 Savola、P.、 "イン・ネットワークのトンネリングを使用したMTUと断片化の問題"、2006年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
Appendix A. Acknowledgements
付録A.謝辞
This work was supported by the National Science Foundation under Grant No. 0083285.
この作品は、グラント番号0083285の下で国立科学財団によってサポートされていました。
Authors' Addresses
著者のアドレス
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
ジョン・W. Heffnerピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグ、PA 15213米国
Phone: 412-268-2329 EMail: jheffner@psc.edu
電話：412-268-2329 Eメール：jheffner@psc.edu
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
マット・マシスピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグ、PA 15213米国
Phone: 412-268-3319 EMail: mathis@psc.edu
電話：412-268-3319 Eメール：mathis@psc.edu
Ben Chandler Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
ベン・チャンドラーピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグ、PA 15213米国
Phone: 412-268-9783 EMail: bchandle@gmail.com
電話：412-268-9783 Eメール：bchandle@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。