[要約] 要約： RFC 3763は、One-way Active Measurement Protocol（OWAMP）の要件を定義しています。OWAMPは、ネットワークの性能測定やトラブルシューティングに使用されるプロトコルです。目的： RFC 3763の目的は、OWAMPの要件を明確に定義し、ネットワークの性能測定における一方向のアクティブな測定を可能にすることです。
Network Working Group S. Shalunov
Request for Comments: 3763 B. Teitelbaum
Category: Informational Internet2
April 2004
One-way Active Measurement Protocol (OWAMP) Requirements
一元配置アクティブ測定プロトコル（OWAMP）要件
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）The Internet Society（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]、[測量]）がありますが、現在、相互運用性の標準はありません。この要件ドキュメントは、ユーザーが両端の異なるベンダーのデバイスを使用して測定を行い、意味のある結果を得ることができるプロトコルを定義することを目的としています。
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一元配置測定を収集する手法を標準化することにより、現在可能なよりもはるかに広いインターネットパスのメッシュでこれらのメトリックが収集される環境を作成したいと考えています。特に説得力のあるビジョンの1つは、往復時間の測定がPingなどのICMPベースのツールを使用して今日の片道遅延の測定を行うオープンな一方向アクティブ測定ビーコンの広範な展開です。非常に正確なタイムスタンプがなくても、多くの実用的な目的、たとえばネットワーク操作で許容できる品質で損失などの特性を測定できます。
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.
代替オウムの実装間の相互運用性をサポートし、「一方向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.
取得した測定結果の可能な限り幅広い使用を促進するために、プロトコルは必要な後処理を必要としません。（これは、真夜中以降のダニからタイムスタンプを標準形式に変換したり、キャリブレーション定数を適用したりするなどの実装の詳細には適用されません。そのような詳細は自然に非表示にする必要があります。）測定セッション中に取得したすべてのデータは、必要に応じてセッションを終了した後に利用可能にする必要があります。データ消費者によって、任意のアルゴリズムを使用して生データからさまざまな特性を計算できるようにします。
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).
測定結果を配布する手段（測定セッションおよびそれ以降に参加するホスト間）を提供する必要があります。最終データの宛先がどこにあるべきかに関してはさまざまなシナリオが存在する可能性があるため、これらは測定要求とは別に呼び出される必要があります（たとえば、受信者は受信者または受信者である可能性があるため、測定結果を送信者に自動的に送信する必要はありません。究極のデータ宛先である3番目のホスト）。
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）さまざまなレベルの機能、柔軟性、および実装の取り組みが必要です。（iii）異なるトランスポートプロトコルを実行する必要がある場合があります。2つのプロトコルが存在する必要があります。1つは実際の測定セッションを実施するため、もう1つはセッションのセットアップ/分解/確認/取得用です。これらのプロトコルは、それぞれオウムテストおよびオウムコントロールと呼ばれます。
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-TESTのみをサポートするが、Owamp-Controlではなく測定セッションを実施するデバイスを使用することが可能です（そのようなデバイスは、1つの形式のセッションセットアッププロトコルなどをサポートする必要がありますが、外部関係者）。
OWAMP-Control would thus become a common protocol for different administrative domains, which may or may not use it for session setup internally.
したがって、Owamp-Controlは、さまざまな管理ドメインの一般的なプロトコルになり、セッションセットアップに使用する場合と使用しない場合があります。
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-Testパケット形式には、普遍的に意味のあるフィールドのみと、最小数のフィールドのみを含める必要があります。
+ 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セルの内部に収まるようにすることができるはずです。
+ 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);
+ ゼロ以上のオウムテストセッションをスケジュールします（オウムコントロールの会話の仲間の間である必要はありません）。
+ start OWAMP-Test sessions simultaneously or at a pre-scheduled per-session times;
+ オウムテストセッションを同時に、またはセッションごとに事前にスケジュールした時間で開始します。
+ retrieve OWAMP-Test session results (of OWAMP-Test sessions scheduled in the current and other OWAMP-Control sessions);
+ OWAMP-TESTセッションの結果（現在およびその他の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-Controlの設計は、長期間の損失を記録する能力を排除するべきではありません。常にピアにネットワークの故障とピアの障害を区別する機能を提供する必要があります。
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.
+ 多くのオウムテストスピーカーは、ソケットインターフェイスを含むマルチタスクオペレーティングシステムを備えた汎用コンピューターになります。これらは、生ネットワークトラフィックを聞くと、必然的により高い損失をもたらします。生のソケットは、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セッションを実行できます（または、そのネットワークからスパムを送信するために）。測定を実行する能力は、すべての送信者に代わって任意のトラフィックを生成する能力に変換されます。
+ 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.
測定サーバーに任意のパケットを生成するように依頼できるようにすることは、管理不可能なセキュリティホールと手ごわい仕様と実装のハードルになると思われます。
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]または1つのホップごとの動作識別コード（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）総リソースが必要です）。または、スケーラビリティの欠陥がない他のアーキテクチャを設計することを不可能にします（原則として可能です）。
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).
これは、パケット内のデータを変更せずに結果を操作できるため、データの整合性の暗号化保証とは異なります。たとえば、OWAMP-TESTパケットが簡単に識別できる場合（例えば、それらはすべて有名なポート番号になります）、中間パーティは、塗りつぶされたリンクでOWAMP-TESTトラフィックを優先行列に配置する可能性があります。測定は、他のトラフィックが経験するものよりもよく見えます。中級者がOwamp-Testパケットを特定するのは簡単ではないはずです（レストランがレストランの批評家を特定するのは簡単ではないように）。
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-Controlストリームを検査したり、積極的に変更したりすることにより、Owamp-Controlを使用してどの情報が交換されるかを学習するために使用される共有秘密の知識なしに、外部の当事者にとってそれを実行不可能にすることが可能であるはずです。
(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.)
（一部の情報は、コミュニケーションの単なる事実と、同時およびその後のオウムテストトラフィックの存在とタイミングから必然的にリークすることが認識されています。）
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-Controlプロトコルの各メッセージ、特定のセッションへの帰属、およびその正確な配置を認証する施設を提供する必要があります。制御プロトコル交換のシーケンス。
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-Test送信者と受信機の間に有効なトラフィックを観察できない場合にのみ有効です。
OWAMP-Control must be resistant to any replay attacks.
Owamp-Controlは、リプレイ攻撃に耐性がなければなりません。
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-Testは、ネットワーク測定のプロトコルです。ネットワークの属性の1つは、パケットの複製です。オウムテストは、重複の測定に適している必要があります。これにより、最近のパケットの再生を含む攻撃に対して脆弱になります。このようなパケットの受信者にとって、重複が悪意があるか自然に発生しているかを判断することは不可能です。
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-TESTは、悪意のあるまたはその他のすべての複製を測定する必要があります。これは遅延攻撃に似ていることに注意してください。攻撃者はパケットを短時間持ち上げてから、それをリリースして受信者に向かう途中で続けることができます。そのような遅延が、レシピエントによる自然に発生する遅延と確実に区別できる方法はありません。
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-Testは、ネットワークをそのまま測定する必要があります。ただし、これにより、処理、分析、または消費の後期段階でデータが消毒されることを妨げないことに注意してください。いくつかの正気のチェック（包含の側で信頼できると見なされ、誤っているとみなされるもの）は、Owamp-Testの受信者がすぐに実行する必要があります。
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).
暗号化セキュリティメカニズムが使用されない完全に「オープン」モードで操作できるはずです。これを「認可されていないモード」と呼びます。このモードでは、ネットワーク容量の飢vationのサービス攻撃のためにプロトコルの使用を防ぐことを防ぐ必須メカニズムを指定する必要があります（たとえば、リクエストで送信することを要求したクライアントにテストデータを送り返すだけです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] Paxson、V.、Almes、G.、Mahdavi、J。およびM. Mathis、「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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Black、D.、Brim、S.、Carpenter、B。and F. Le Faucheur、「ホップの動作識別コード」、RFC 3140、2001年6月。
[BRIX] Brix 1000 Verifier, http://www.brixnet.com/products/brix1000.html
[Brix] Brix 1000 Verifier、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/
[熟した]熟したNCCテスト - トラフィック測定ホーム、http：//www.ripe.net/test-traffic/
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
[測量]測量士のホームページ、http：//www.advanced.org/surveyor/
Stanislav Shalunov
Stanislav Shalunov
EMail: shalunov@internet2.edu
Benjamin Teitelbaum
ベンジャミン・テイテルバウム
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。