RFC3763 日本語訳

Network Working Group                                        S. Shalunov
Request for Comments: 3763                                 B. Teitelbaum
Category: Informational                                        Internet2
                                                              April 2004

Shalunovがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3763年のB.タイテルバウムカテゴリ: 情報のInternet2 April 2004

        One-way Active Measurement Protocol (OWAMP) Requirements

一方向アクティブな測定プロトコル(OWAMP)要件

Status of this Memo

この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.

Copyright(C)インターネット協会(2004)。 All rights reserved。

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)規格のための要件を指定します。 プロトコルは一方向損失などの一方向遅れ、および他の単方向の特性を測定できます。

1.  Motivations and Goals

1. 動機と目標

   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パフォーマンスMetrics(IPPM)ワーキンググループはインターネット経路の向こう側に一方向パケット遅れ[RFC2679]と損失[RFC2680]で標準化過程測定基準を提案しました。 現在、これらの測定基準の収集を実装するいくつかの測定プラットホームがありますが([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

(GPS)とCDMAのベースの時間ソース、ホストがますます彼らにとって利用可能にする手頃な全地球側位システムのますます広い有用性で、それが許容する時間ソースは精度がオンであることが見られた遅れより実質的に良い直接か彼らのNTPのプライマリ(層1)の時間サーバの近接を通したインターネットをタイムスタンプパケットに接待します。 IPPMの一方向アクティブな測定を集めるためのテクニックを標準化することによって、私たちは、これらの測定基準が横切って集められるかもしれない環境を作成することを望んでいます。

Shalunov & Teitelbaum        Informational                      [Page 1]

RFC 3763                   OWAMP Requirements                 April 2004

[1ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

   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.

インターネット経路の現在可能であるよりはるかに広いメッシュ。 特にビジョンを強制する1つはピングのような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.

代替のOWAMP実装の間の相互運用性をサポートして、「一方向ピング」が平凡になることができた世界を可能にするように、どのようにテストストリームを開始するか、そして、どのようにテストパケットを交換するか、そして、どのように試験の成績を検索するかを指定する規格が必要です。 その後のセクションで詳細な機能条件書を与えます。

2.  Functional Requirements

2. 機能条件書

   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.

非単独個体の特性(パケットの列車、背中合わせのtuplesなどに関連するものなどの)とアプリケーショントラフィックシミュレーションは扱われる必要はありません。 しかしながら、彼らは、実用的であると考えられるなら扱われて、他に反して目標を設計しないかもしれません。

2.1.  Keeping All Data for Post-processing

2.1. 後工程の間のすべてのデータを保ちます。

   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.

得られた測定結果の最も広い活用可能性を容易にするために、プロトコルは少しの必要なポスト処理も必要とするべきではありません。 (これは真夜中以来のカチカチする音からのタイムスタンプを標準形に変換するか、または較正定数を適用などなどの実装の詳細に適用されません; そのような詳細は自然に隠されるべきです。) 生データから任意のアルゴリズムを使用することで様々な特性を計算できるようにデータ消費者によって望まれるならセッションが終わっていた後に測定セッションの間に得られたすべてのデータが利用可能であるべきです。

Shalunov & Teitelbaum        Informational                      [Page 2]

RFC 3763                   OWAMP Requirements                 April 2004

[2ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

2.2.  Result Distribution

2.2. 結果分配

   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.

同時に、直接それらの目的地(潜在的に大きい中間的転送の必要性のない)に結果を移す能力を提供するべきです。

2.3.  Protocol Separation

2.3. プロトコル分離

   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つのプロトコルが存在するべきです: 実測セッションを行うためのものとセッションセットアップ/分解/確認/検索のための別。 これらのプロトコルはさらにそれぞれ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-テストをサポートするだけであるデバイスを使用するのは可能であるべきです(そのようなデバイスが、必ず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-コントロールは異なった管理ドメインへの一般的なプロトコルになるでしょう。(ドメインはセッションセットアップに内部的にそれを使用するかもしれません)。

2.4.  Test Protocol

2.4. テストプロトコル

   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.

+、さまざまな測定ノードで実装に適してください。

Shalunov & Teitelbaum        Informational                      [Page 3]

RFC 3763                   OWAMP Requirements                 April 2004

[3ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

   +  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.

OWAMP-テストが十分小さいパケットであると生成するのは可能であるべきです、いつが要約されたように実用的であるなら+が単一のATMセルの中でそれぞれ合うのを。

   +  Data needed to calculate experimental errors on the final result
      should be included in every OWAMP-Test packet.

+ データは、最終的な結果における実験誤差があらゆるOWAMP-テストパケットに含まれるべきであると見込む必要がありました。

2.5.  Control Protocol

2.5. 制御プロトコル

   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-コントロールデザインは損失の長期間を記録する能力を排除するべきではありません。 それはいつもネットワークと同輩失敗を見分ける能力を同輩に提供するべきです。

Shalunov & Teitelbaum        Informational                      [Page 4]

RFC 3763                   OWAMP Requirements                 April 2004

[4ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

2.6.  Support for Measurements with Different Packet Types

2.6. 異なったパケットタイプがある測定値のサポート

   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-テストスピーカーは多重タスキングがある汎用計算機がソケットインタフェースを含んでいるオペレーティングシステムであったならそうするでしょう。 これらには、生のネットワークトラフィックを聞くとき、より高い損失が必然的にあるでしょう。 生のソケットは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.

人が任意のパケットを生成するために測定サーバを尋ねるのを許容するのが「非-処理しやす」セキュリティーホール、あなどりがたい仕様、および実装ハードルになるように見えます。

   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が全体のパケットタイプスペースの小さい部分空間をサポートするのを必要とするだけです。 すなわち、与えられたDifferentiated Services Codepoint(DSCP)[RFC2474]か与えられたPer Hop Behavior Identification Code(PHB ID)[RFC3140]と共に測定値を行うのは可能であるべきです。

Shalunov & Teitelbaum        Informational                      [Page 5]

RFC 3763                   OWAMP Requirements                 April 2004

[5ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

3.  Scalability

3. スケーラビリティ

   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.

どのようにプロトコルを使用するか、そして、どの測定値を行ったらよいかを決めるのは、プロトコルユーザの責任です。

4.  Security Considerations

4. セキュリティ問題

4.1.  Authentication

4.1. 認証

   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.

また、そのようなパーティーが見ることによって得られたどんな情報も使用するのも、実行不可能であるべきです、(他)の正規ユーザーをまねるためにプロトコルトランザクションを変更するか、または開始して。

4.2.  Authorization

4.2. 承認

   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.

プロトコルのデザインで、それはどんな中間的パーティーも結果をそれらが干渉が全く試みられなかったかどうかということであるだろうより良く見せるのを非常に難しくする走行セッションまで可能になるべきです。

Shalunov & Teitelbaum        Informational                      [Page 6]

RFC 3763                   OWAMP Requirements                 April 2004

[6ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

   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-テストパケットは特定しやすいなら(例えば、それらは皆、ウェルノウン・ポート番号に来ます)、その結果、測定の結果が他のトラフィックによって経験されることより良く見えるのを確実にしながら、中間的パーティーは混雑しているリンクにOWAMP-テストトラフィックを優先待ち行列に置くかもしれません。 中間的パーティーがOWAMP-テストパケットを特定するのは、簡単であるはずがありません(レストランがレストラン評論家を特定するのが、簡単であるはずであるだけではないように)。

4.4.  Secrecy/Confidentiality

4.4. 秘密保持/秘密性

   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-テストトラフィックのコミュニケーションの単なる事実と存在とタイミングから必然的に漏れると認められます。)

4.5.  Integrity

4.5. 保全

   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-テスト送付者と受信機の間の有効なトラフィックを観測できないときだけ、セキュリティの特性は有効です。

4.6.  Replay Attacks

4.6. 反射攻撃

   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-テストは複製の測定に適していなければなりません。 これで、それは最近のパケットを再演することを伴う攻撃に被害を受け易くなるでしょう。 そのようなパケットの受取人にとって、複製が悪意がありますかそれとも自然に起こっているかを決定するのは不可能です。

Shalunov & Teitelbaum        Informational                      [Page 7]

RFC 3763                   OWAMP Requirements                 April 2004

[7ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

   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-テスト受取人によって実行されるべきです。

4.7.  Modes of Operation

4.7. 運転モード

   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接続は引き渡されました); そして、それは、ワームがまもなさに(例えば、オープン形式要求の承認をレートで制限して、人間がオープン形式要求をすることができるだけであるのを確実にする)非常に多くのホストにテストデータを送るのにプロトコルを使用するのを防ぎます。

Shalunov & Teitelbaum        Informational                      [Page 8]

RFC 3763                   OWAMP Requirements                 April 2004

[8ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

   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.

実装をより処理しやすくするように、別の選択肢とモードの数は絶対実用的な最小限に保たれるべきです。 セキュリティに関連するものは何でも達成するためのただ一つのメカニズムを選ぶのが可能であるところでは、そのような選択を仕様フェーズで作って、規格に入れるべきです。

5.  IANA Considerations

5. IANA問題

   Relevant IANA considerations will be placed into the protocol
   specification document itself, and not into the requirements
   document.

関連IANA問題は要件ドキュメントではなく、プロトコル仕様ドキュメント自体に置かれるでしょう。

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [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パフォーマンス測定基準のためのフレームワーク」、RFC2330)は1998がそうするかもしれません。

   [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分野)の定義」RFC2474(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における、メートル法のA One-道の遅れ」、RFC2679、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における、メートル法のA One-道のパケット損失」、RFC2680、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.Le Faucheur、「ホップ振舞い識別コード」、RFC3140、2001年6月。

6.2.  Informative References

6.2. 有益な参照

   [BRIX]     Brix 1000 Verifier,
              http://www.brixnet.com/products/brix1000.html

[果物の糖度の単位]果物の糖度の単位1000検証、 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 Test-トラフィックMeasurementsホーム、 http://www.ripe.net/test-traffic/

   [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/

[測量士]測量士ホームページ、 http://www.advanced.org/surveyor/

Shalunov & Teitelbaum        Informational                      [Page 9]

RFC 3763                   OWAMP Requirements                 April 2004

[9ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

7.  Authors' Addresses

7. 作者のアドレス

   Stanislav Shalunov

スタニスラフShalunov

   EMail: shalunov@internet2.edu

メール: shalunov@internet2.edu

   Benjamin Teitelbaum

ベンジャミン・タイテルバウム

   EMail: ben@internet2.edu

メール: ben@internet2.edu

Shalunov & Teitelbaum        Informational                     [Page 10]

RFC 3763                   OWAMP Requirements                 April 2004

[10ページ]RFC3763OWAMP要件2004年4月の情報のShalunovとタイテルバウム

8.  Full Copyright Statement

8. 完全な著作権宣言文

   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.

Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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機能のための基金は現在、インターネット協会によって提供されます。

Shalunov & Teitelbaum        Informational                     [Page 11]

ShalunovとタイテルバウムInformationalです。[11ページ]