この文書はRFC 4963の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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).
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.
今日のインターネットのいくつかの状況で、ＩＰｖ４のパケット分割は、十
分な強靭性を持ちません。高いデータ信号速度では、１６ビットのＩＰ識別
フィールドはＩＰパケットの不当な組み立てを防ぐのに十分な大きさがあり
ません、そして、ＴＣＰとＵＤＰチェックサムは、結果的に発生する崩壊し
たデータグラムが上位プロトコル層に渡されるのを防ぐは不十分です。この
文書は、問題を示すいくつかの容易に再生できる実験について説明して、こ
れらの観測の運用上のいくつかの示唆について議論します。
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.
ＩＰｖ４ヘッダはデータ信号速度が今日達成可能なのより数桁低かった時代
に設計されました。この文書はＩＰ識別(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.
ＩＰ分割がネットワークの効率を悪くするのは[Kent87]でよく知られていま
す。この文書は異種の問題を提示します、これは性能を悪化させるだけでな
く、頻繁なデータ変造を生むことがあります。 これは、時には、あらゆる
データグラムを断片化する最近のＵＤＰバルク輸送ツールの増殖により特に
問題になります。
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.
さらに、ＭＴＵ探索問題[RFC2923]で使うＩＰヘッダの分割禁止(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."
"データグラムの識別子の選択はデータグラムの断片を特定する方法を提
供する必要性に基づいています。断片を組立てるプロトコルモジュール
は、同じソース、あて先、プロトコル、識別子の破片を同じデータグラ
ムに属する断片を判断します。その結果、送信者はインターネットでデー
タグラム(または、それの断片)が存在しているかもしれない間に、ソー
スとあて先の対とプロトコルに対し一意になるように、識別子を選ばな
ければなりません"
Strict conformance to this standard limits transmissions in one
direction between any address pair to no more than 65536 packets per
protocol (e.g., TCP, UDP, or ICMP) per maximum packet lifetime.
この規格に厳しく適合すると、任意のアドレス対で、一方向に対し、最大の
パケット生存期間に、プロトコル（例えばＴＣＰやＵＤＰやＩＣＭＰ）毎に、
パケットを65536個未満へ制限します。
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.
これはあまりにも低い最大データ送信速度を意味するので、この規定に従わ
ないホストが存在します。例えば、ホストが１５００バイトで最大パケット
生存時間が３０秒のパケットを送信する場合、パケット生存時間あたり
65535個のパケットを超えないためには約26Mbpsに制限されます。1ギガバイ
トのインターフェースを１５００バイトパケットで満たすには65535個のパ
ケットを１秒未満で送る必要があり、これは短すぎるパケット生存時間でい
くつかのパスの往復遅延時間より小さいですこの要件は広く無視されます。
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フィールドをランダムに設定します
[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.
データグラムのすべての断片が届くか、または再組立て期限([RFC0791]で15
秒と示されます)が切れるまで、ＩＰ受信者は再組立バッファに断片を格納
します。データグラムの断片はプロトコル番号とIDフィールド値とソース/
宛先アドレス対で関連付けられます。送付者が再組立て期限以前にIDフィー
ルドを再利用するなら、異なるデータグラムの断片を不当に継ぎ合わせし
て(「関連付け誤り」)、上位層プロトコルに届けるのが可能になります。
A case of particular concern is when mis-association is self-
propagating. This occurs, for example, when there is reliable
ordering of packets and the first fragment of a datagram is lost in
the network. The rest of the fragments are stored in the fragment
reassembly buffer, and when the sender wraps the ID field, the first
fragment of the new datagram will be mis-associated with the rest of
the old datagram. The new datagram will be now be incomplete (since
it is missing its first fragment), so the rest of it will be saved in
the fragment reassembly buffer, forming a cycle that repeats every
65536 datagrams. It is possible to have a number of simultaneous
cycles, bounded by the size of the fragment reassembly buffer.
特別に関心のある事例は、関連付け誤りが自己伝播する場合です。これは、
例えば、パケットの信頼できる順序があり、データグラムの最初の断片が
ネットワークでなくなるときに起こります。断片の残りは断片は再組立て
バッファの中に格納されます、そして、送付者がIDフィールドを再使用す
るとき、新しいデータグラムの最初の断片は古いデータグラムの残りと誤っ
て関連付けられるでしょう。新しいデータグラムは(最初の断片が失われ
ているので)不完全になります、残りの断片は再組立てバッファの中に保
存され、65536個のデータグラム毎に同じことが繰り返されます。これは、
同時の何サイクルもの誤りの発生が可能で、断片再組立てバッファサイズ
により制限されます。
IPv6 is considerably less vulnerable to this type of problem, since
its fragment header contains a 32-bit identification field [RFC2460].
Mis-association will only be a problem at packet rates 65536 times
higher than for IPv4.
ＩＰｖ６は、断片ヘッダが32ビットの識別子フィールドを含むので
[RFC2460]、この種類の問題の被害を受けにくいです。誤関連付けは
ＩＰｖ４より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.
関連付けを誤った断片が届けられるとき、トランスポート層のチェックサ
ムは不正確はこれらのデータグラムを検出し、捨てるべきです。 データ
グラムが捨てられるとき、混雑以外の要因での損失となるので、特に大き
い混雑ウィンドウが必要なときに、損失フィードバック輻輳制御アルゴリ
ズムの性能問題が生じるかもしれません。
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]。
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.
ＵＤＰでの断片化の実際的な衝撃をテストするために、私たちは特定ネット
ワーク上で大きいデータ集合を転送するためのＴＣＰに代わる手段として使
用されるように設計されたＵＤＰの大量のデータ伝送プロトコルを使用する
ことで一連の実験を行いました。自動化された実験を容易にする簡潔なイン
タフェースがあるので、Reliable Blast UDP(RBUDP)とQUANTAネットワーク
ツールキット[QUANTA]の一部がツールとして選択されました。RBUDPを使用
するという決定はトランスポートプロトコル自体の詳細にほとんど無関係で
した。誤りを検出する追加手段を持たず、ＩＰ断片化を使用する構成ができ
る、任意のＵＤＰトランスポートプロトコルも同じ結果になるでしょう。
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.
ＵＤＰバルク転送ツールで転送されたファイル上で誤りを診断するために、
私たちはそれぞれのデータグラムの各断片に埋め込まれた一連番号とＭＤ
５チェックサムを含むファイル形式を使用しました。したがって、関連付
け誤りの断片によって引き起こされ誤りとランダム誤りを区別するのが可
能でした。私たちは２つの異なる種類のファイルを使用しました。１つは
すべてのＵＤＰチェックサムが一定になるように作られました−私たちは、
これを「一定」のデータセットと呼ぶつもりです。もう１つはＵＤＰチェッ
クサムが一様ランダムになるように構成しました−「ランダム」のデータ
セット。すべてのテストは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.
ＵＤＰ大容量ファイル輸送ツールは、利用可能なデータ信号速度(100メガ
ビット毎秒)よりわずかに遅い速度で、データセットを１組のホスト間で
送るのに使用されました。それぞれの転送の始まり頃に、短時間の２つ目
の転送が、第一の転送におけるパケット損失を引き起こすために始められ
ました。第一の転送の存在中に、私たちは100分の1パーセントぐらい率の
関連付け誤りを観測しました。
Tests run with the "constant" dataset resulted in corruption on all
mis-associated fragments, that is, corruption on the order of a few
hundredths of a percent. In sending approximately 10 TB of "random"
datasets, we observed 8847668 UDP checksum errors and 121 corruptions
of the data due to mis-associated fragments.
「一定」のデータセットで実行したテストではすべての関連付け誤りの断片
が変造をもたらしました、すなわち、100分の数パーセントの誤りです。お
よそ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.
関連付け誤りを避ける最も簡単な方法は経路ＭＴＵ探索[RFC1191]を実行する
ことによって全体で断片化を避けることです[RFC1191][RFC4821]。しかしな
がら、すべてのアプリケーションでこれがいつも可能であるというわけでは
ありません。さらに、ＭＴＵ探索問題[RFC2923]のための次善策として、いく
らかのＴＣＰ実装と通信装置が、DFビットをクリアするか、無視することで
経路ＭＴＵ探索を無効にするメカニズムを提供します。これはＩＰｖ４を使
う全てのプロトコルを、ＭＴＵ探索を使うものも含めて、関連付け誤の危険
に曝します。
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 IDの選択を制御し、受信
者は再組立てタイムアウトを制御するので、双方の間に何らかの相互保障が
必要でしょう。 さらに、一般に、速い送信者の断片の関連付け誤りが起き
ないほど十分低く、かつ、遅い送信者の断片が組立てなおされる前に無条件
に捨てられないだけ十分に大きいタイムアウトを設定するのは可能ではあり
ません。したがって、タイムアウトとIP ID選択は、相手毎に１個の割合で
必要があるでしょう。また、ＮＡＴがＩＰアドレスをキーとした相手毎のテー
ブルを壊す事も、ありそうです。私たちは、最も一般的に生じる環境下での
関連付け誤りを、適応型のタイムアウトで防げそうと信じますが、これらの
問題の解決策を推薦するのは、この文書の範囲外です。
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.
特に注意する場合はＩＰｖ４のトンネルカプセル化ペイロードです。ＭＴＵ
探索の困難に対処するために[RFC4459]、トンネルはペイロードのDFビットが
設定されていても２地点間のＩＰ分割に依存するかもしれません [RFC4301]。
このようなモードで、２つのトンネル終点がＩＰ終端のホストとして振る舞
い、トンネルのトラヒックは全て同じプロトコルタイプを持ちます。したがっ
て、トンネルパケットの集合レートは最大のパケット生存期間あたり65536
個を超えないか、またはトンネルのデータは関連付け誤りの危険に曝される
事になります。ＴＣＰの様なＭＴＵを発見をするプロトコルさえ影響される
でしょう。トンネルのオペレータは受信者の再組立てタイムアウトを、トン
ネルの最高速度を考えて確実に関連付け誤りが生じないように短くするよう
にするべきです。
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を確実にしてても、ＮＡＴやトンネルの存在がアプリケーションをIP ID
空間競合の危険に曝すかもしれません。さらに、トンネルなどの、ネットワー
ク終端ホストが見ることができないか制御できない装置が関連付け誤りを引
き起こすかもしれません。低速で送信する分割アプリケーションでも、同時
に高速送信の非分割アプリケーションが動作すると、危険に曝されるかもし
れません。上で説明したように、受信者は、競合の可能性を減少するか、排
除する実装をするかもしれませんが、送信者が何をしているか受信者が知る
メカニズムは現時点でありません。結果として、ＩＰｖ４分割を使用してい
るアプリケーションのための、関連付け誤りから決定論的か統計的に保護さ
れるてるかどうかを知る、一般的なメカニズムもありません。
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.
関連付け誤りを防ぐのが不可能か非実用的である状況の下では、ＩＰ上の任
意の層での強い完全性検査の使用で影響が緩和されるかもしれません。これ
は暗号の認証を使用する場合の自然な副作用です。例えば、ＩＰｓｅｃの認
証ヘッダ[RFC4302]は崩壊したデータグラムを廃棄し、それらの上位層への配
送を阻止します。ＳＣＴの長さ３２ビットのチェックサム[RFC2960]などの、
より強いトランスポート層チェックサムはかなり助けるかもしれません。ア
プリケーション層では、ＳＳＨメッセージ認証コード[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.
一般に、ＩＰｖ４パケット分割に依存するアプリケーションは、[Kent87]で
書かれた問題同様に、ここで書いた問題を考慮すべきです。高速で送信
(100Mbpsか、それ以上)し、ＩＰｖ４パケット分割に依存するアプリケーショ
ンと、本来パケット分割すべきでないトラヒックを故意に分割するデバイス
(例えば、トンネル)は、特に用心深く、データ完全性を確実にするために強
いメカニズムを導入するべきです。
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.
悪意がある者が、１組のホストが分割化している通信をしているのを知って
いるなら、通信を崩壊させる機会を持つかもしれません。偽造ソースアドレ
スの"後位"の断片(オフセットがゼロ以上のもの)で、攻撃者は故意に上で説
明される不正を引き起こす場合がありえます。この脆弱性を利用するのは、
通信のソースと宛先アドレスとプロトコル番号と分割境界の知識だけが必
要です。それはポートや一連番号に関する知識を必要としません。
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.
攻撃者が経路上のパケットを見ることができるなら、攻撃プロフィールは
完全なセグメントを注入するのと同様です。この攻撃を使用するのは、盲
目的にの中断をより簡単にして、サービス妨害を引き起こすために使用さ
れるかもしれません。私たちは、ＩＰｖ４パケット分割を使用する通信だ
けがおそらく傷つきやすいと信じています。本書では概説された問題の本
質のために、重要なアプリケーションでＩＰｖ４分割の使用は、安全上の
配慮にかかわらず、賢明でないかもしれません、。
8. Informative References
8. 有益な参考文献
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered
harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October
1987.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[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.
[Stone00] Stone, J. and C. Partridge, "When The CRC and TCP
Checksum Disagree", Proc. SIGCOMM 2000 vol. 30, No. 4,
October 2000.
[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.
[Bellovin02] Bellovin, S., "A Technique for Counting NATted Hosts",
Internet Measurement Conference, Proceedings of the 2nd
ACM SIGCOMM Workshop on Internet Measurement, November
2002.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 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.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
Appendix A. Acknowledgements
付録Ａ．謝辞
This work was supported by the National Science Foundation under
Grant No. 0083285.
この仕事はグラント番号００８３２８５で全米科学財団によって支持
されました。
Authors' Addresses
著者のアドレス
John W. Heffner
Pittsburgh Supercomputing Center
4400 Fifth Avenue
Pittsburgh, PA 15213
US
Phone: 412-268-2329
EMail: jheffner@psc.edu
Matt Mathis
Pittsburgh Supercomputing Center
4400 Fifth Avenue
Pittsburgh, PA 15213
US
Phone: 412-268-3319
EMail: mathis@psc.edu
Ben Chandler
Pittsburgh Supercomputing Center
4400 Fifth Avenue
Pittsburgh, PA 15213
US
Phone: 412-268-9783
EMail: bchandle@gmail.com
Full Copyright Statement
完全著作権表示
Copyright (C) The IETF Trust (2007).
著作権（Ｃ）ＩＥＴＦ信託（２００７）
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とＩＥＴＦ信託インターネット技術標準化タスクフォースは、明確にも暗黙
にも、この情報の使用が権利の侵害しないことや商業利用や特別の目的への
利用に適当である事の保障を含め、全ての保証を拒否します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。