RFC4963 日本語訳
4963 IPv4 Reassembly Errors at High Data Rates. J. Heffner, M. Mathis,B. Chandler. July 2007. (Format: TXT=22399 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Heffner Request for Comments: 4963 M. Mathis Category: Informational B. Chandler PSC July 2007
コメントを求めるワーキンググループJ.ヘフナー要求をネットワークでつないでください: 4963年のM.マシスカテゴリ: 情報のB.ろうそく屋PSC2007年7月
IPv4 Reassembly Errors at High Data Rates
高いデータ信号速度におけるIPv4 Reassembly誤り
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).
IETFが信じる著作権(C)(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チェックサムは、結果として起こる崩壊したデータグラムが、より高いプロトコル層に提供されるのを防ぐためには不十分です。 この注意は、問題を示すいくつかの容易に再生している実験について説明して、これらの観測の操作上の含意のいくつかについて議論します。
Heffner, et al. Informational [Page 1] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[1ページ]のRFC4963IPv4 Reassembly誤り
1. Introduction
1. 序論
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ヘッダーで噛み付かれたFragment(DF)ではなく、ドンを無視する何らかのネットワーク装置があります。 この設備は、データを崩壊させるように間接的に適切に実装しているプロトコルとアプリケーションを暴露します。
2. Wrapping the IP ID Field
2. IP ID分野を包装します。
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."
「データグラムのためのIdentifierの選択は唯一特定のデータグラムの断片を特定する方法を提供する必要性に基づいています。」 それらに同じソース、目的地、プロトコル、およびIdentifierがあるなら、断片を組み立てるプロトコルモジュールは、同じデータグラムに属すために断片を判断します。 「その結果、送付者はインターネットでデータグラム(または、それのどんな断片も)が生きるかもしれない時のこのソース、目的地組、およびプロトコルに特有になるようにIdentifierを選ばなければなりません。」
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未満のパケットへのどんなアドレス組の間の一方向に制限します。
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.
明確に、すべてではなく、無分別に低い最大のデータ信号速度を含意するので、ホストはこの規格の後をつけます。 例えば、1パケット生存期間あたり65535のパケットを超える前に、30秒の最大のパケット生存期間がある1500年のバイトのパケットを送るホストはおよそ26Mbpsだけで発信できました。 または、1秒未満について65536のパケットを送る無分別に短い最大のパケット生存期間を1500年のバイトのパケットで1つのGbpsインタフェースを満たすのは必要とします、いくつかの経路の往復の時間より少なくて。 この要件は広く無視されます。
Heffner, et al. Informational [Page 2] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[2ページ]のRFC4963IPv4 Reassembly誤り
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.
さらに、IP ID分野で65536個のデータグラムに一度値を再利用するのが、最も良いケースであることに注意する価値があります。 いくつかの実装が、IP ID分野の再利用がprobabilisticallyにレートを全く送りながら起こるカーネル[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分野を包装するとき、新しいデータグラムの最初の断片は古いデータグラムの残りに誤関連するでしょう。 新しいデータグラムが現在不完全であること(最初の断片を逃しているので)である、したがって、それの残りは断片再アセンブリバッファで保存されて、1サイクルの間、それを形成すると、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倍高いパケットレートで問題になるにすぎないでしょう。
3. Effects of Mis-Associated Fragments
3. 誤関連している断片の効果
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.
誤関連している断片が提供されるとき、トランスポート層checksummingは不正確であるとしてこれらのデータグラムを検出して、それらを捨てるべきです。 データグラムが捨てられるとき、損失フィードバック輻輳制御アルゴリズムのための性能問題を生じさせるかもしれません、特に大きい混雑ウィンドウが必要であるときに、ある量の非充血性の損失を導入するので。
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^に一度応用層に32個のデータグラムを提供したと予想します。
Heffner, et al. Informational [Page 3] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[3ページ]のRFC4963IPv4 Reassembly誤り
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]の確率を増強しそうであるかもしれません。 また、いくつかのアプリケーションか上位レベル・プロトコルが加速するためにchecksummingしながら、興味を失うかもしれません、この習慣は他の理由で、データの信頼性が重要であるときに[Stone00]、危険であることがわかりましたが。
4. Experimental Observations
4. 実験観測
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の大量のデータトランスポート・プロトコルを使用することで一連の実験を走らせました。 ツール、それには自動化された実験を容易にした清潔なインタフェースがあるので、Reliable Blast 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つの異なったタイプのファイルを使用しました。 1つが組み立てられたので、すべてのUDPチェックサムが一定でした--私たちは、これを「一定」のデータセットと呼ぶつもりです。 もう片方が構成されたので、UDPチェックサムは一様に無作為でした--「無作為」のデータセット。 すべてのテストがそれらが1500年のバイトのMTUと共に標準のファースト・イーサネットで断片化されたように1524年のバイトのデータグラムで送られた400MBのファイルを使用し終わっていました。
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)で1組のホストの間にデータセットを送るのに使用されました。 それぞれの流れの始まり頃に、簡潔な二次流は、プライマリ流れにおけるパケット損失を引き起こすために始められました。 プライマリ流れの寿命の間中、私たちはパーセントのいくつかの100分の1の注文の誤会合速度を通常観測しました。
Heffner, et al. Informational [Page 4] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[4ページ]のRFC4963IPv4 Reassembly誤り
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.
「一定」のデータセットで実行されたテストはすべての誤関連している断片(すなわち、パーセントのいくつかの100分の1の注文の不正)で不正をもたらしました。 「無作為」のデータセットのおよそ10TBを送る際に、私たちは誤関連している断片のためデータの8847668のUDPチェックサム誤りと121の贈収賄を観測しました。
5. Preventing Mis-Association
5. 誤協会を防ぎます。
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ビットをきれいにするか、または無視することによって経路MTU探索を無効にするためにメカニズムを提供します。 そうするのは、IPv4、誤協会誤りにMTU発見に参加するものさえ使用することですべてのプロトコルを暴露するでしょう。
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選択は、1同輩あたり1個のベースでする必要があるでしょう。 また、NATがIPアドレスによって合わせられたどんな1同輩あたりのテーブルも壊すのも、ありそうです。 これらの問題にソリューションを推薦するために、このドキュメントの範囲の中にそれはありません、私たちが、それが最も一般的に起こる状況の下で誤協会であると適応型のタイムアウトが防ぎそうである同輩信じていますが。
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]における困難に対処するために、トンネルは2つの終点の間の断片化に依存するかもしれません、ペイロードがDFビット[RFC4301]でマークされても。 そのようなモードで、2つのトンネル終点がIP終わりのホストとして振る舞います、同じプロトコルタイプがあるすべてのトンネルを堀られたトラフィックで。 したがって、トンネルを堀られたパケットの集合レートが最大のパケット生存期間あたり65536を超えないかもしれませんか、またはトンネルを堀られたデータは可能な誤協会に暴露されるようになります。 TCPなどの発見をMTUにするプロトコルさえ影響を受けるでしょう。 トンネルのオペレータは犠牲者の再アセンブリタイムアウトが確実にトンネルの最高率を考えて、誤協会が起こることができないくらい短くなるようにするべきです。
Heffner, et al. Informational [Page 5] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[5ページ]のRFC4963IPv4 Reassembly誤り
6. Mitigating Mis-Association
6. 誤協会を緩和します。
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を確実にして、終わりのホストが慎重に仕様に従っても、NATsかトンネルの存在は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]がどんな崩壊したデータグラム、防止も捨てる、それら、上側の層に配送してください。 SCTPなどの、より強いトランスポート層チェックサム(長さ[RFC2960]は32ビットである)はかなり助けるかもしれません。 応用層では、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]に記録されたそれらの問題と同様に。 高速(100Mbpsか、より高いことの注文)で発信している間にIPv4断片化に依存するアプリケーションと故意にそうでなければ、非断片化しているトラフィック(例えば、トンネル)に断片化を取り入れるデバイスは、特に用心深く、データ保全を確実にするために強いメカニズムを紹介するはずです。
Heffner, et al. Informational [Page 6] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[6ページ]のRFC4963IPv4 Reassembly誤り
7. Security Considerations
7. セキュリティ問題
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.
悪意がある実体が、1組のホストが断片化しているストリームを使用することで交信しているのを知っているなら、流れを崩壊させる機会をそれに与えるかもしれません。 偽造ソースアドレスがある送付の「高い」断片(オフセットゼロ以上があるそれら)で、攻撃者は故意に上で説明されるように不正を引き起こす場合があります。 この脆弱性を利用するのはソースに関する唯一の知識と流れ、プロトコル番号、および断片限界の送付先アドレスを必要とします。 それはポートか一連番号に関する知識を必要としません。
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断片化の重要なアプリケーションの使用は賢明でないかもしれません、安全上の配慮にかかわらず。
8. Informative References
8. 有益な参照
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October 1987.
[Kent87] ケントとC.とJ.ムガール人、「有害であると考えられた断片化」、Proc。 1987年10月のSIGCOMM87年vol.17、No.5。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、2000年9月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、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] Networking vol.6、No.5(1998年10月)のストーン、J.、グリーンワルド、M.、Partridge、C.、およびJ.ヒューズ、「本当のデータの上のチェックサムとCRCのパフォーマンス」、IEEE/ ACM Transactions。
[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。 2000年10月のSIGCOMM2000vol.30、No.4。
Heffner, et al. Informational [Page 7] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[7ページ]のRFC4963IPv4 Reassembly誤り
[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.
[量子]の彼、E.、Alimohideen、J.、Eliason、J.、Krishnaprasad、N.、リー、J.、ユー、O.、およびT.DeFanti、「量子:」 「フォトニックネットワークの上の高性能データ配送のためのツールキット」、Future Generationコンピュータシステムズ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ホストを数えるためのテクニック」、インターネット測定コンファレンス、インターネット測定(2002年11月)の第2ACM SIGCOMMワークショップの議事。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] YlonenとT.とC.Lonvick、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola、P.、「MTUと断片化がコネで発行する、-、-トンネリングをネットワークでつないでください、」、RFC4459、4月2006日
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] マシスとM.とJ.ヘフナー、「Packetization層の経路MTU発見」、RFC4821、2007年3月。
Heffner, et al. Informational [Page 8] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[8ページ]のRFC4963IPv4 Reassembly誤り
Appendix A. Acknowledgements
付録A.承認
This work was supported by the National Science Foundation under Grant No. 0083285.
この仕事はグラントNo.0083285の下で国立科学財団によってサポートされました。
Authors' Addresses
作者のアドレス
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
ジョン・W.ヘフナー・ピッツバーグスーパーコンピューティングセンター4400五番街PA15213ピッツバーグ(米国)
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五番街PA15213ピッツバーグ(米国)
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五番街PA15213ピッツバーグ(米国)
Phone: 412-268-9783 EMail: bchandle@gmail.com
以下に電話をしてください。 412-268-9783 メールしてください: bchandle@gmail.com
Heffner, et al. Informational [Page 9] RFC 4963 IPv4 Reassembly Errors at High Data Rates July 2007
ヘフナー、他 高いデータ信号速度2007年7月における情報[9ページ]のRFC4963IPv4 Reassembly誤り
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Heffner, et al. Informational [Page 10]
ヘフナー、他 情報[10ページ]
一覧
スポンサーリンク