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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

mkdir ディレクトリを作成する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る