Network Working Group S. Shalunov
Request for Comments: 3763 B. Teitelbaum
Category: Informational Internet2
April 2004
One-way Active Measurement Protocol (OWAMP) Requirements
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 Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss.
良い時間ソースの成長可用性は、ノードをネットワーク化すると、それは高精度に一方向IPのパフォーマンスメトリックを測定することがますます可能となります。相互運用可能な方法でこれを行うには、そのような測定のための共通プロトコルが必要です。この文書は、一方向活性測定プロトコル（OWAMP）規格の要件を指定します。プロトコルは、一方向遅延、ならびに一方向損失のような他の一方向の特性を測定することができます。
The IETF IP Performance Metrics (IPPM) working group has proposed standards track metrics for one-way packet delay [RFC2679] and loss [RFC 2680] across Internet paths. Although there are now several measurement platforms that implement the collection of these metrics ([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a standard for interoperability. This requirements document is aimed at defining a protocol that allows users to do measurements using devices from different vendors at both ends and get meaningful results.
IETF IPパフォーマンス・メトリック（IPPM）ワーキンググループは、基準は、インターネットパス間で一方向のパケット遅延[RFC2679]と損失[RFC 2680]のメトリックを追跡提案しました。これらのメトリックの収集を実現するいくつかの測定プラットフォーム（[CQOS]、[BRIX]、[RIPE]、[SURVEYOR]）は、今がありますが、相互運用性のための標準は現在ありません。この要件ドキュメントは、ユーザーが両端で異なるベンダの機器を使用して測定を行い、意味のある結果を得ることを可能にするプロトコルを定義することを目的としています。
With the increasingly wide availability of affordable global positioning system (GPS) and CDMA based time sources, hosts increasingly have available to them time sources that allow hosts to time-stamp packets with accuracies substantially better than the delays seen on the Internet--either directly or through their proximity to NTP primary (stratum 1) time servers. By standardizing a technique for collecting IPPM one-way active measurements, we hope to create an environment where these metrics may be collected across a far broader mesh of Internet paths than is currently possible. One particularly compelling vision is of widespread deployment of open one-way active measurement beacons that would make measurements of one-way delay as commonplace as measurements of round-trip time are today using ICMP-based tools like ping. Even without very accurate timestamps one can measure characteristics such as loss with quality acceptable for many practical purposes, e.g., network operations.
手頃な価格の全地球測位システム（GPS）のますます広い可用性とCDMAベースのタイムソースを使用すると、ホストはますますインターネット上で見られる遅延よりも実質的に良好な精度を持つタイムスタンプパケットにホストを許可それらに利用可能なタイムソースを持っている - のいずれかを直接またはNTPの主（ストラタム1）タイムサーバへの近接による。 IPPM片道アクティブ測定値を収集するための技術を標準化することによって、私たちは、これらのメトリックが現在可能であるよりも、インターネットパスのはるかに広いメッシュ全体に収集することができる環境を作成したいと考えています。一つの特に魅力的なビジョンは、ラウンドトリップ時間の測定がpingのようなICMPベースのツールを使用して、今日あるとして当たり前のように一方向遅延の測定になるだろう、オープン一方向アクティブ測定ビーコンの広範囲の展開です。非常に正確なタイムスタンプことなく、1つは、例えば、多くの実用的な目的のために許容可能な品質とネットワーク・オペレーションを、そのような損失等の特性を測定することができます。
To support interoperability between alternative OWAMP implementations and make possible a world where "one-way ping" could become commonplace, a standard is required that specifies how test streams are initiated, how test packets are exchanged, and how test results are retrieved. Detailed functional requirements are given in the subsequent section.
代替OWAMP実装間の相互運用性をサポートし、「片道pingが」当たり前になる可能性の世界を可能にするために、標準テストストリームがテストパケットが交換されているか、開始され、テスト結果がどのように取得される方法を指定することが必要です。詳細な機能要件は、後続のセクションに記載されています。
The protocol(s) should provide the ability to measure, record, and distribute the results of measurements of one-way singleton network characteristics such as characteristics defined in [RFC2679] and [RFC2680]. Result reporting, sampling, and time stamps are to be within the framework of [RFC2330].
プロトコル（単数または複数）は、[RFC2679]及び[RFC2680]で定義される特性として一方向シングルトンネットワーク特性の測定結果を、測定記録、および配布する能力を提供すべきです。結果の報告、サンプリング、およびタイムスタンプは、[RFC2330]の枠内にあることがあります。
It should be possible to measure arbitrary one-way singleton characteristics (e.g., loss, median delay, mean delay, jitter, 90th percentile of delay, etc.); this is achieved by keeping all the raw data for post-processing by the final data consumer, as specified in section 2.1. Since RFC2679 and RFC2680 standardize metrics based on Poisson sampling processes, Poisson streams must be supported by the protocol(s).
任意の一方向シングルトン特性を測定することが可能であるべきである（例えば、損失、メジアン遅延、遅延、ジッタ、遅延の90パーセンタイル、等を意味します）。これはセクション2.1で指定されるように、最終的なデータコンシューマによって後処理のためにすべての生データを保持することによって達成されます。 RFC2679とRFC2680はポアソンサンプリング法に基づいて測定基準を標準化するため、ポアソンストリームプロトコル（単数または複数）によってサポートされなければなりません。
Non-singleton characteristics (such as those related to trains of packets, back-to-back tuples, and so forth) and application traffic simulation need not be addressed. However, they may be addressed if considered practical and not in contradiction to other design goals.
非シングルトン（例えば、パケットの列に関連するものとして、バックツーバックタプルなど）の特性とアプリケーショントラフィックシミュレーションが対処する必要はありません。他の設計目標に矛盾では実用的ではないと考えている場合しかし、彼らは対処することができます。
To facilitate the broadest possible use of obtained measurement results, the protocol(s) should not necessitate any required post-processing. (This does not apply to implementation details such as converting timestamps from ticks since midnight into a canonical form or applying calibration constants; such details should naturally be hidden.) All data obtained during a measurement session should be available after the session is finished if desired by the data consumer so that various characteristics can be computed from the raw data using arbitrary algorithms.
得られた測定結果の最も広い可能な使用を容易にするために、プロトコル（単数または複数）は、任意の必要な後処理を必要としないはずです。 （これは、標準形に午前0時からダニからタイムスタンプを変換または校正定数を適用するように実装の詳細には適用されない;そのような詳細は、天然に隠さなければならない。）測定セッション中に得られたすべてのデータが利用可能であるべき所望の場合にセッションが終了した後にデータコンシューマによってように種々の特性は、任意のアルゴリズムを使用して生データから計算することができます。
A means to distribute measurement results (between hosts participating in a measurement session and beyond) should be provided. Since there can exist a wide variety of scenarios as to where the final data destination should be, these should be invoked separately from measurement requests (e.g., receiver should not have to automatically send measurement results to the sender, since it may be the receiver or a third host that are the ultimate data destination).
（超えて測定セッションに参加しているホストとの間）の測定結果を配布する手段が提供されるべきです。最終的なデータ送信先があるべき場所へようなシナリオの広範囲が存在することができるので、これらは、測定要求（例えば、別に呼び出されるべきことは、受信機であってもよいので、受信機は、自動的に送信者に測定結果を送信する必要はありません最終的なデータの送信先である第三のホスト）。
At the same time, ability to transfer results directly to their destination (without need for potentially large intermediate transfers) should be provided.
同時に、（潜在的に大きな中間転送を必要とすることなく）その宛先に直接結果を転送する能力が提供されるべきです。
Since measurement session setup and the actual measurement session (i) are different tasks; (ii) require different levels of functionality, flexibility, and implementation effort; (iii) may need to run over different transport protocols, there should exist two protocols: one for conducting the actual measurement session and another for session setup/teardown/confirmation/retrieval. These protocols are further referred to as OWAMP-Test and OWAMP-Control, respectively.
測定セッションの設定と実際の測定セッション（i）は、異なるタスクなので、 （ii）の機能性、柔軟性、および実装作業の異なるレベルを必要とします。実際の測定セッションを行うための1つのセッションセットアップ/ティアダウン/確認/検索するための他の：（iii）の異なるトランスポートプロトコルを介して実行する必要があり、2つのプロトコルが存在しなければなりません。これらのプロトコルはさらに、それぞれ、OWAMPテストとOWAMP - コントロールと呼ばれます。
It should be possible to use devices that only support OWAMP-Test but not OWAMP-Control to conduct measurement sessions (such devices will necessarily need to support one form of session setup protocol or the other, but it doesn't have to be known to external parties).
（そのようなデバイスは、必ずしもセッションセットアッププロトコルまたは他の一の形態をサポートする必要があるでしょうが、それはに知られていなくても、測定セッションを実施するだけOWAMP - テストをサポートするデバイスではなく、OWAMP - コントロールを使用することが可能でなければなりません外部の関係者）。
OWAMP-Control would thus become a common protocol for different administrative domains, which may or may not use it for session setup internally.
OWAMP - コントロールは、このようにまたは内部セッションセットアップのためにそれを使用しない場合があり、異なる管理ドメインのための共通のプロトコルになるでしょう。
The test protocol needs to be implemented on all measurement nodes and should therefore have the following characteristics:
試験プロトコルは、全ての測定ノードで実施する必要があり、従って、以下の特性を有するべきです。
+ Be lightweight and easy to implement.
+軽量かつ実装が容易です。
+ Be suitable for implementation on a wide range of measurement nodes.
+測定ノードの広範囲に実装に適しています。
+ Allow UDP as the transport protocol, since the protocol needs to be able to measure individual packet delivery times and has to run on various machines (see the section "Support for Measurements with Different Packet Types" below for further discussion).
プロトコルは、個々のパケット配信時間を測定できるようにする必要があり、様々なマシン上で実行することがあるので+、トランスポートプロトコルとしてUDPを許可する（さらなる議論については、下記の「異なるパケットタイプと測定のためのサポート」を参照してください）。
+ Support varying packet sizes and network services (e.g., DSCP marking).
+サポート変化するパケットサイズとネットワークサービス（例えば、DSCPマーキング）。
+ Be as simple as possible, but no simpler than necessary to implement requirements set forth in this document; the OWAMP-Test packet format should include only universally meaningful fields, and minimum number of them.
+できるだけ簡単なものはないが、必要以上に簡単一切は、この文書に記載された要件を実装します。 OWAMPテストパケットフォーマットは、普遍的に意味のあるフィールド、およびそれらの最小数を含むべきです。
+ If practical, it should be possible to generate OWAMP-Test packets small enough, so that when encapsulated, each fits inside a single ATM cell.
カプセル化されたとき、それぞれが単一のATMセルの内部に収まるように+実用的な場合には、十分に小さいOWAMP - テストパケットを生成することが可能であるべきです。
+ Data needed to calculate experimental errors on the final result should be included in every OWAMP-Test packet.
+データは、すべてのOWAMPテストパケットに含まれるべきである最終的な結果に実験誤差を計算するために必要。
Control protocol needs to provide the capability to:
制御プロトコルはに機能を提供する必要があります：
+ authenticate peers to each other using a common authentication method that doesn't require building any new authentication infrastructure, such as user ID and a shared secret;
+、ユーザーIDと共有秘密など、新たな認証インフラストラクチャを構築する必要がない一般的な認証方法を使用してお互いにピアを認証。
+ schedule zero or more OWAMP-Test sessions (which do not have to be between the peers of OWAMP-Control conversation);
+スケジュールゼロまたは（OWAMP制御会話のピア間である必要はない）よりOWAMPテストセッション。
+ start OWAMP-Test sessions simultaneously or at a pre-scheduled per-session times;
+同時にまたは事前にスケジュールごとのセッション時間にOWAMPテストセッションを開始します。
+ retrieve OWAMP-Test session results (of OWAMP-Test sessions scheduled in the current and other OWAMP-Control sessions);
+（現在のおよび他のOWAMP制御セッションでスケジュールOWAMPテストセッションの）OWAMP - テストセッションの結果を取得します。
+ confirm graceful completion of sessions and allow either side to abort a session prematurely.
+セッションの優雅な完了を確認し、いずれかの側が途中でセッションを中止することができます。
The OWAMP-Control design should not preclude the ability to record extended periods of losses. It should always provide peers with the ability to distinguish between network and peer failures.
OWAMP - コントロールの設計は、損失の長時間を記録する機能を排除すべきではありません。それは、常にネットワークとピアの障害を区別する能力をピアを提供する必要があります。
Since the notion of a packet of type P from [RFC2330], section 13 doesn't always imply precise definition of packet type, some decisions narrowing the scope of possible packet types need to be made at measurement protocol design stage. Further, measurement with packets of certain types, while feasible in more closed settings than those implied by OWAMP, become very hard to perform in an open inter-domain fashion (e.g., measurements with particular packets with broken IP checksum or particular loose source routing options).
[RFC2330]から式Pのパケットの概念ので、セクション13は、常にパケットタイプの正確な定義を意味するものではない、可能なパケットタイプの範囲を狭めるいくつかの決定は、測定プロトコルの設計段階で行われる必要があります。特定の種類のパケットでさらに、測定、OWAMPによって暗示されるものよりも閉じた設定で可能ながら、オープンドメイン間の様式で行うのは非常に困難になる（例えば、壊れたIPチェックサム、または特定のルーズソースルーティングオプションを使用して特定のパケットを用いた測定）。
In addition, very general packet type specification could result in several problems:
また、非常に一般的なパケットタイプの仕様では、いくつかの問題が生じる可能性が：
+ Many OWAMP-Test speakers will be general purpose computers with a multitasking operating system that includes a socket interface. These will inevitably have higher losses when listening to raw network traffic. Raw sockets will induce higher loss rate than one would have with UDP measurements.
+多くのOWAMP - テストスピーカーは、ソケット・インタフェースを備えてマルチタスクオペレーティングシステムと汎用コンピュータとなります。生のネットワークトラフィックを聞いたときに、これらは、必然的に高い損失を持つことになります。 rawソケットは、1つのUDP測定を持っているだろうより高い損失率を誘導します。
+ It's not at all clear (short of standardizing tcpdump syntax) how to describe formally the filter that a receiver should use to listen for test traffic.
+これは、正式に受信機がテストトラフィックをリッスンするために使用すべきフィルタを記述する方法（tcpdumpの構文を標準化するの短い）は全く明らかではありません。
+ Suppose an identity of an authenticated user becomes compromised. Now the attacker could use that to run TCP sessions to the rlogin port of machines around servers that trust this user to perform measurements (or, less drastically, to send spam from that network). The ability to perform measurements is transformed into an ability to generate arbitrary traffic on behalf of all the senders an OWAMP-Control server controls.
+認証されたユーザのアイデンティティが侵害されたと仮定します。今、攻撃者は（そのネットワークからのスパムを送信するために、あまり劇的、または）測定を実行するには、このユーザーを信頼し、サーバの周りのマシンのrloginポートへのTCPセッションを実行することを使用することができます。測定を実行する能力は、すべての送信者OWAMP制御サーバーコントロールの代わりに任意のトラフィックを生成する能力に変換されます。
+ Carefully crafted packets could cause disruption to some link-layer protocols. Implementors can't know what to disallow (scrambling is different for different link-layer technologies).
+慎重パケットは、いくつかのリンク層プロトコルに混乱を引き起こす可能性が細工。実装者は、（スクランブルが異なるリンク層技術のために異なっている）禁止するかを知ることはできません。
It appears that allowing one to ask a measurement server to generate arbitrary packets becomes an unmanageable security hole and a formidable specification and implementation hurdle.
1つは、任意のパケットを生成する測定サーバに依頼することができことは手に負えないセキュリティホールと恐るべき仕様と実装のハードルになっていることが表示されます。
For these reasons, we only require OWAMP to support a small subspace of the whole packet type space. Namely, it should be possible to conduct measurements with a given Differentiated Services Codepoint (DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB ID) [RFC3140].
これらの理由から、我々は全体のパケットタイプ空間の小さな部分空間をサポートするためのOWAMPが必要です。すなわち、与えられた差別化サービスコードポイント（DSCP）[RFC2474]または所与当たりホップ行動識別コード（PHB ID）[RFC3140]を用いて測定を行うことが可能であるべきです。
While some measurement architecture designs have inherent scalability problems (e.g., a full mesh of always-on measurements among N measurement nodes requires O(N^2) total resources, such as storage space and link capacity), OWAMP itself should not exaggerate the problem or make it impossible (where it is in principle possible) to design other architectures that are free of scalability deficiencies.
いくつかの測定アーキテクチャの設計は固有のスケーラビリティの問題を抱えている（例えば、N計測ノード間で測定常時オンのフルメッシュは、このような収納スペースとリンク容量としてO（N ^ 2）の合計リソースを必要とする）が、OWAMP自体は問題を誇張べきではありませんまたはスケーラビリティの欠陥を含まない他のアーキテクチャを設計する（これは原理的には可能です）、それは不可能になります。
It is the protocol user's responsibility to decide how to use the protocol and which measurements to conduct.
プロトコルを使用すると、どの測定が実施する方法を決定するためのプロトコルのユーザーの責任です。
It should be possible to authenticate peers to each other using a user ID and a shared secret. It should be infeasible for any external party without knowledge of the shared secret to obtain any information about it by observing, initiating, or modifying protocol transactions.
ユーザーIDと共有秘密を使用して、相互にピアを認証することが可能です。共有秘密の知識がなくても任意の外部の当事者が、観測開始、またはプロトコルのトランザクションを変更することで、それについての情報を入手することが実行不可能でなければなりません。
It should also be infeasible for such party to use any information obtained by observing, modifying or initiating protocol transactions to impersonate (other) valid users.
当該当事者は、観察修正または（他の）有効なユーザーを偽装するために、プロトコルのトランザクションを開始することによって得た情報を使用することも実行不可能でなければなりません。
Authorization shall normally be performed on the basis of the authenticated identity (such as username) and the specification shall require all implementations to support such a mode of authorization. Different identities (or classes of identities) can have different testing privileges. The use of authorization for arriving at specific policy decisions (such as whether to allow a specific test with a specific source and destination and with a given test send schedule -- which would determine the average network capacity utilization -- at a given time) is up to the users.
承認は通常、（例えば、ユーザ名など）認証されたアイデンティティに基づいて行われなければならないと仕様が承認のようなモードをサポートするために、すべての実装を要求しなければなりません。異なるアイデンティティ（またはアイデンティティのクラスは）異なる検査権限を持つことができます。 （ - 平均ネットワーク稼働率を決定することになる - そのような特定の送信元と宛先とし、所定の試験送信スケジュールに特定のテストを可能にするかどうかなど、所与の時間に）特定の政策決定に到達するための許可の使用でありますユーザーまで。
4.3. Being Hard to Interfere with by Applying Special Treatment to Measurement Packets
4.3. 測定パケットに特別な処理を施すことによりに干渉しにくいという
The design of the protocol should make it possible to run sessions that would make it very difficult for any intermediate party to make results appear better than they would be if no interference was attempted.
プロトコルの設計は、それが可能な結果が全く干渉が試行されなかった場合、彼らはだろうより良い見えるようにする任意の中間パーティーのために、それは非常に困難になるだろうセッションを実行するために行う必要があります。
This is different from cryptographic assurance of data integrity, because one can manipulate the results without changing any data in the packets. For example, if OWAMP-Test packets are easy to identify (e.g., they all come to a well-known port number), an intermediate party might place OWAMP-Test traffic into a priority queue at a congested link thus ensuring that the results of the measurement appear better than what would be experienced by other traffic. It should not be easy for intermediate parties to identify OWAMP-Test packets (just as it should not be easy for restaurants to identify restaurant critics).
1パケット内のデータを変更せずに結果を操作することができますので、これは、データの整合性の暗号保証は異なっています。 OWAMP - テストパケットを識別しやすくしている場合たとえば、（例えば、それらはすべて、よく知られたポート番号に来る）、中間の当事者は、このようにその結果を確実に混雑したリンクでプライオリティキューにOWAMP - テストのトラフィックを置くかもしれません測定は、他のトラフィックによって経験されるものより良く見えます。中間当事者がOWAMP - テストパケットを識別することは（レストランでは、レストラン評論家を特定することは容易ではないはずと同じように）簡単ではないはずです。
It should be possible to make it infeasible for any outside party without knowledge of the shared secret being used to learn what information is exchanged using OWAMP-Control by inspecting an OWAMP-Control stream or actively modifying it.
OWAMP - コントロール・ストリームを検査するか、積極的にそれを修正することにより、OWAMP - コントロールを使用して交換される情報を学ぶために使用されている共有秘密の知識がなくても任意の外部の第三者のためにそれを実行不可能にすることが可能でなければなりません。
(It is recognized that some information will inevitably leak from the mere fact of communication and from the presence and timing of concurrent and subsequent OWAMP-Test traffic.)
（一部の情報は、必然的に、通信の同時およびその後OWAMPテストトラフィックの存在およびタイミングから単なる事実から漏れるであろうことが認識されます。）
So that it is possible to detect any interference during a conversation (other than the detention of some messages), facility must be provided to authenticate each message of the OWAMP-Control protocol, its attribution to a given session, and its exact placement in the sequence of control protocol exchanges.
それは（いくつかのメッセージの留置以外）会話の間の干渉を検出することが可能であるように、ファシリティは、各OWAMP制御プロトコルのメッセージ、所与のセッションへの帰属、及びその正確な配置を認証するために提供されなければなりません制御プロトコル交換のシーケンス。
It must also be possible to authenticate each message of the test protocol and its attribution to a specific session, so that modifications of OWAMP-Test messages can be detected. It must be possible to do this in a fashion that does not require timestamps themselves to be encrypted; in this case, security properties are valid only when an attacker cannot observe valid traffic between the OWAMP-Test sender and receiver.
またOWAMPテストメッセージの変更を検出することができるように、特定のセッションに各試験プロトコルのメッセージとその属性を認証することが可能でなければなりません。それ自体が暗号化されるためにタイムスタンプを必要としない方法でこれを行うことが可能でなければなりません。この場合には、セキュリティプロパティは、攻撃者がOWAMP - テスト送信者と受信者の間で有効なトラフィックを観察することができない場合にのみ有効です。
OWAMP-Control must be resistant to any replay attacks.
OWAMP - コントロールは、任意のリプレイ攻撃への耐性がなければなりません。
OWAMP-Test, on the other hand, is a protocol for network measurement. One of the attributes of networks is packet duplication. OWAMP-Test has to be suitable for measurement of duplication. This would make it vulnerable to attacks that involve replaying a recent packet. For the recipient of such a packet it is impossible to determine whether the duplication is malicious or naturally occurring.
OWAMPテストは、一方で、ネットワーク測定のためのプロトコルです。ネットワークの属性の1つは、パケットの重複です。 OWAMPテストは、複製の測定に適していることがあります。これは、最近のパケットを再生伴う攻撃に対して脆弱になるだろう。このようなパケットの受信者にとっては、重複が悪意のあるまたは天然に存在するかどうかを判断することは不可能です。
OWAMP-Test should measure all duplication -- malicious or otherwise. Note that this is similar to delay attacks: an attacker can hold up a packet for some short period of time and then release it to continue on its way to the recipient. There's no way such delay can be reliably distinguished from naturally occurring delay by the recipient.
悪意のあるまたはその他 - OWAMP - テストは、すべての重複を測定する必要があります。攻撃者は、時間のいくつかの短い期間のためのパケットを保持して、受信者にその途中で継続する、それを解放することができます。これは、攻撃を遅らせることが似ていることに注意してください。このような遅延は確実に自然に受信者によって遅延が発生するのを区別することができる方法はありません。
OWAMP-Test should measure the network as it was. Note, however, that this does not prevent the data from being sanitized at a later stage of processing, analysis, or consumption. Some sanity checks (those that are deemed reliable and erring on the side of inclusion) should be performed by OWAMP-Test recipient immediately.
それがあったとしてOWAMPテストは、ネットワークを測定する必要があります。これは、処理、解析、または消費の後の段階で消毒されるのデータを妨げないことが、注意してください。いくつかの健全性チェック（信頼性の包含の側に身を誤っと認められるもの）は直ちにOWAMPテスト受信者によって行われるべきです。
Since the protocol(s) will be used in widely varying circumstances using widely varying equipment, it is necessary to be able to support varying degrees of security modes of operation. The parameters to be considered include: confidentiality, data origin authentication, integrity and replay protection.
プロトコル（単数または複数）が広く変化する装置を使用して広く変化する状況で使用されるので、操作のセキュリティモードの様々な程度をサポートできることが必要です。考慮すべきパラメータは、機密性、データ発信元認証、完全性、再生保護を。
It should also be possible to operate in a mode where all security mechanisms are enabled and security objectives are realized to the fullest extent possible. We call this "encrypted mode".
また、すべてのセキュリティ・メカニズムが有効になっていると、セキュリティの目標は、可能な最大限に実現されているモードで動作することが可能なはずです。私たちは、この「暗号化モード」と呼びます。
Since timestamp encryption takes a certain amount of time, which may be hard to predict on some devices (with a time-sharing OS), a mode should be provided that is similar to encrypted mode, but in which timestamps are not encrypted. In this mode, all security properties of the encrypted mode that can be retained without timestamp encryption should be present. We call this "authenticated mode".
タイムスタンプの暗号化（時分割OSで）いくつかのデバイス上で予測することは難しいかもしれある程度の時間を要するため、モードは、暗号化モードと類似しているが提供されるべきであるが、ここで、タイムスタンプは、暗号化されていません。このモードでは、タイムスタンプの暗号化せずに保持することができ、暗号化モードのすべてのセキュリティプロパティが存在しなければなりません。私たちは、この「認証済みモード」と呼びます。
It should be possible to operate in a completely "open" mode, where no cryptographic security mechanisms are used. We call this "unauthenticated mode". In this mode, mandatory-to-use mechanisms must be specified that prevent the use of the protocol for network capacity starvation denial-of-service attacks (e.g., only sending test data back to the client that requested them to be sent with the request delivered over a TCP connection), and that prevent a worm from using the protocol to send test data to a very large number of hosts in a short time (e.g., ensuring that open mode requests can only be made by humans, rate-limiting the acceptance of open mode requests).
何の暗号化セキュリティ・メカニズムが使用されていない完全に「オープン」モードで動作することが可能なはずです。私たちは、この「認証されていないモード」と呼びます。このモードでは、義務的に使用できるメカニズムはバック要求とともに送信されるようにそれらを要求したクライアントへのテストデータを送信するネットワーク容量の飢餓サービス拒否攻撃（例えば、のためのプロトコルの使用を防ぐことを指定する必要があります）TCPコネクションを介して配信され、それは例えば、オープンモード要求は人間だけで行うことができることを保証する（短時間でのホストの非常に大きな数にテストデータを送信するためのプロトコルを使用してからワームを防ぐため、速度制限オープンモードの要求の受付）。
To make implementation more manageable, the number of other options and modes should be kept to the absolute practical minimum. Where choosing a single mechanism for achieving anything related to security is possible, such choice should be made at specification phase and be put into the standard.
実装は、より管理しやすくするために、他のオプションとモードの数が絶対的な実用最小限に抑える必要があります。セキュリティに関連する何かを達成するための単一のメカニズムを選択することが可能である場合には、そのような選択は、仕様段階でなされるべきであると、標準に入れること。
Relevant IANA considerations will be placed into the protocol specification document itself, and not into the requirements document.
関連IANAの考慮はプロトコル仕様文書自体にではなく、要件文書に配置されます。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.とM.マシス、 "IPパフォーマンス・メトリックのための枠組み"、RFC 2330、1998年5月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "IPPMための一方向遅延メトリック"、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "IPPMための一方向パケット損失メトリック"、RFC 2680、1999年9月。
[RFC3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]黒、D.、つば、S.、大工、B.およびF.ルFaucheur、 "当たりホップ行動識別コード"、RFC 3140、2001年6月。
[BRIX] Brix 1000 Verifier, http://www.brixnet.com/products/brix1000.html
[BRIX]ブリックス千検証、http://www.brixnet.com/products/brix1000.html
[CQOS] CQOS Home Page, http://www.cqos.com/
[CQOS] CQOSホームページ、http://www.cqos.com/
[RIPE] RIPE NCC Test-Traffic Measurements home, http://www.ripe.net/test-traffic/
[RIPE] RIPE NCCのテスト・トラフィック測定ホーム、http://www.ripe.net/test-traffic/
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
[SURVEYOR]サーベイヤーホームページ、http://www.advanced.org/surveyor/
Stanislav Shalunov
スタンは、ハリーの宇野V対引っ張っています
EMail: shalunov@internet2.edu
メールアドレス：shalunov@internet2.edu
Benjamin Teitelbaum
ベンジャミンTeitelbaum
EMail: ben@internet2.edu
メールアドレス：ben@internet2.edu
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。