この文書はRFC3689の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group K. Carlberg
Request for Comments: 3689 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
General Requirements for
Emergency Telecommunication Service (ETS)
緊急通信サービス（ＥＴＳ）の一般的要求条件
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.
Abstract
概要
This document presents a list of general requirements in support of
Emergency Telecommunications Service (ETS). Solutions to these
requirements are not presented in this document. Additional
requirements pertaining to specific applications, or types of
applications, are to be specified in separate document(s).
この書類は緊急通信サービス（ＥＴＳ）をサポートする一般的な要求条件の
リストを提出します。これらの要求条件に対する解決策がこの文書で提出さ
れません。特定のアプリケーションやアプリケーション種別に関する追加の
要求条件が、別の文書で指定されるはずです。
1. Introduction
1. はじめに
Effective telecommunications capabilities can be imperative to
facilitate immediate recovery operations for serious disaster events,
such as, hurricanes, floods, earthquakes, and terrorist attacks.
Disasters can happen any time, any place, unexpectedly. Quick
response for recovery operations requires immediate access to any
public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet
access via online terminals, IP telephones, and wireless PDAs. The
commercial telecommunications infrastructure is rapidly evolving to
Internet-based technology. Therefore, the Internet community needs
to consider how it can best support emergency management and recovery
operations.
効果的通信能力は、ハリケーンや洪水や地震やテロリスト攻撃などの大災害
からの当面の復興事業の促進を命令され得ます。大災害がいつでもどこでも
不意に起こりえます。素早い復興事業には公共通信能力への即刻のアクセス
を必要とします。これらの能力は次を含みます：従来の電話、携帯電話、オ
ンラインの端末やＩＰ電話や無線ＰＤＡからのインターネット・アクセス。
商用通信基盤はインターネットベースの技術で急速に進展しています。それ
故に、インターネット共同体はどのように緊急管理と復興事業をサポートす
るか考える必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [1].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と
"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と
"OPTIONAL"はＢＣＰ１４、ＲＦＣ２１１９[1]で記述されるように解
釈します。
1.1. Terminology
1.1. 用語
Label:
ラベル：
The term label has been used for a number of years in various IETF
protocols. It is simply an identifier. It can be manifested in
the form of a numeric, alphanumeric value, or a specific bit
pattern, within a field of a packet header. The exact form is
dependent on the protocol in which it is used.
用語ラベルは長年、種々なＩＥＴＦプロトコルで使われました。これは単
純に識別子です。これは数や英数字の値や特定のビットパターンのかたち
で、パケットヘッダのフィールドに存在できます。正確な形式は使われる
プロトコルに依存します。
An example of a label can be found in RFC 3031; the Multiprotocol
Label Switching Architecture. Another example can be found in RFC
2597 (and updated by RFC 3260); a bit pattern for the Assured
Forwarding PHB group. This latter case is a type of label that
does not involve routing. Note that specification of labels is
outside the scope of this document. Further comments on labels
are discussed below in section 3.
ラベルの例はＲＦＣ３０３１にあります；マルチプロトコルラベル交換体
系。もう１つの例はＲＦＣ２５９７（とＲＦＣ３２６０での更新）にあり
ます；確実転送ＰＨＢグループのビットパターン。後者はルーティングに
関係しないラベルです。ラベルの仕様がこの文書の範囲外であることに注
意してください。ラベルについてのこれ以上のコメントは３章で論じられ
ます。
1.2. Existing Emergency Related Standards
1.2. 既存の緊急関連標準
The following are standards from other organizations that are
specifically aimed at supporting emergency communications. Most
of these standards specify telephony mechanisms or define
telephony related labels.
次が特に緊急通信をサポートすることに対する他の組織の標準です。こ
れらの標準の大部分が電話メカニズムを指定するか、あるいは電話関連
のラベルを定義します。
Standard / Organization
標準 / 組織
--------------------------
1) T1.631 / ANSI
2) E.106 / ITU
3) F.706 / ITU
4) H.460.4 / ITU
5) I.255.3 / ITU
The first specifies an indicator for SS7 networks that signals the
need for a High Probability of Completion (HPC) service. This
indicator is termed National Security / Emergency Preparedness
(NS/EP) The T1.631 standard [2] is the basis for the U.S. Government
Emergency Telecommunications Service (GETS) [7].
最初の仕様書は、高確率完了（ＨＰＣ）サービスで必要な信号の、ＳＳ７網
の表示を指定します。この表示は国家機密／緊急時準備（ＮＳ／ＥＰ）と呼
ばれます。T１.６３１標準[2]は合衆国政府緊急通信サービス（ＧＥＴＳ）
[7]の基礎です。
The second standard describes functional capabilities for the Public
Switched Telephone Network (PSTN) to support International Emergency
Preparedness System (IEPS) [3]. From the PSTN perspective, one can
view NS/EP as a standard with national boundaries, while IEPS is an
extension to international boundaries for telephony.
２番目の標準は公衆交換電話網（ＰＳＴＮ）の国際緊急準備システム（ＩＥ
ＰＳ）[3]をサポートする機能能力を記述します。ＰＳＴＮの見地から、ＮＳ
／ＥＰは国内標準と見なすことができ、他方ＩＥＰＳは国際電話への拡張で
す。
The third standard extends IEPS beyond the scope of telephony into
other forms that encompass multimedia [4].
３番目の標準は電話の範囲を超えてマルチメディア[4]をカバーする他の形式
にＩＥＰＳを拡張します。
The fourth and fifth standard focuses on a multi-level labeling
mechanism distinguishing emergency type traffic from that which is
not. The former case focuses on call signaling for H.323 networks
[5], while the latter has been applied for both SS7 [6] and data
networks.
４番目そして５番目の標準は緊急種別トラフィックを他と区別する多レベル
のラベルメカニズムに焦点を合わせます。前者はＨ.３２３ネットワーク[5]
の呼信号に焦点を合わせ、後者はＳＳ７[6]とデータネットワーク両方に適用
されます。
While the above standards are outside the scope of the IETF, they do
represent existing efforts in the area of emergency communications,
as opposed to conceptual of potential possibilities. They act as
example manifestations of Emergency Telecommunications Service (ETS).
上記の標準がＩＥＴＦの範囲外であるが、概念的に潜在的な可能性ではなく、
緊急通信のエリアの既存の努力を示します。これらは緊急通信サービス（Ｅ
ＴＳ）の例を表明する役を務めます。
1.3. Problem
1.3. 問題
One problem faced by the IEPREP working group entails how, and to
what degree, support for these standards are to be realized within
the Internet architecture and the existing suite of IETF standards
and associated working groups. This support could be in the form of
interoperability with corresponding IETF protocols.
ＩＥＰＲＥＰ作業班が直面した問題の１つは、どのようにそしてどのぐらい
これらの標準のサポートがインターネット体系で理解されているかと、既存
のＩＥＴＦ標準群と関連作業班です。このサポートは対応するＩＥＴＦと互
換性であり得ます。
A subsequent problem is to ensure that requirements associated with
potential support is not focused just on IP telephony applications.
The I-Am-Alive (IAA) database system is an example of an ETS type
application used in Japan that supports both signaled and non-
signaled access by users [10]. It is a distributed database system
that provides registration, querying, and reply primitives to
participants during times of an emergency (e.g., an earthquake) so
that others can make an after-the-event determination about the
status of a person. In this case, a separate signaling protocol like
SIP is not always required to establish or maintain a connection.
次の問題は潜在的可能性の必要条件がＩＰ電話アプリケーションのサポート
にだけ焦点を合わせないことを保証することです。私は生きてる（ＩＡＡ）
データベースシステムは日本で使用されているＥＴＳ種別アプリケーション
の例で、これはユーザによる信号と非信号アクセスの両方をサポートします
[10]。これは分散データベースシステムで、緊急（例えば地震）時の関係者
の登録と問合せと応答プリミティブをサポートし、他者がイベント後の個人
の状態を知る事ができます。この場合、接続の確立や維持に、ＳＩＰのよう
な別の信号プロトコルが常に必要ではありません。
Given the case where signaling is optional, requirements and
subsequent solutions that address these problems must not assume the
existence of signaling and must be able to support applications that
only have labels in data packets. These label(s) may be in various
places, such as the application or IP header.
信号の使用は任意である場合に、これらの問題を扱う要求条件と解決策は信
号の存在を想定してはならず、データパケットにラベルを持つだけのアプリ
ケーションをサポートすることができなければなりません。ラベルはアプリ
ケーションやＩＰヘッダのような種々な場所にありえます。
2. Scope
2. 範囲
This document defines a set of general system requirements to achieve
support for ETS and addressing the problem space presented in Section
1.3. In defining these requirements, we consider known systems such
as GETS and IAA that represent existing manifestations of emergency
related systems. These two examples also represent a broad spectrum
of characteristics that range from signaling & interactive non-
elastic applications to non-signaled & elastic applications.
この文書はＥＴＳを実現するための一般的システム要求条件を定義し、１.３
章で公開した問題を扱います。これらの要求条件を定義する際に、我々はＧ
ＥＴＳやＩＡＡの様な緊急関連システムの既存の存在を考慮します。これら
の２つの例は、信号型で対話的非柔軟アプリケーションから、非信号型柔軟
アプリケーションまで及ぶ広範囲の特徴を表します。
We stress that ETS, and its associated requirements, is not the only
means of supporting authorized emergency communications. It is
simply an approach influenced by existing systems and standards.
我々はＥＴＳとそれに関連した要求条件が公的緊急通信をサポートする唯一
の手段ではないと強調します。これは既存のシステムと標準に影響を与える
単純な方法です。
Solutions to requirements are not defined. This document does not
specify protocol enhancements or specifications. Requirements for
specific types of applications that go beyond the general set stated
in section 3 are to be specified in other document(s). At the
current writing of this document, [9] has been written for the case
of IP telephony.
要求条件に対する解決策が定義されません。この文書はプロトコル拡張や仕
様を指定しません。３章で述べる一般的な話ではない、特定の種類のアプリ
ケーションの要求条件は他の文書で指定されるはずです。この文書の執筆時
点で、[9]がＩＰ電話の事例のために書かれました。
The current IEPREP charter stipulates that any proposed solution to
support ETS that responds to the requirements of this document are to
be developed in other working groups. We note that other specific
requirements (like that of IP telephony) may be defined as an
extension of the general requirements presented in section 3 below.
現在のＩＥＰＲＥＰ憲章は、この文書の要求条件に対応してＥＴＳをサポー
トするための提案された解決策は、他の作業班で開発されると明記します。
我々は（ＩＰ電話ような）他の特定の要求条件が下記の３章の一般的要求条
件の拡張と定義されるかもしれないことを指摘します。
2.1. Out of Scope
2.1. 範囲外
While the problem space stated in section 1.3 includes standards
related to telephony, this document is meant to be broader in scope.
Hence, emulation of specific architectures, like the PSTN, or focus
on a specific application is out of scope. Further, the
specifications of requirements that are aimed at adhering to
regulations or laws of governments is also out of the scope of this
document. The focus of the IETF and its working groups is technical
positions that follow the architecture of the Internet.
１.３章で述べられた問題が電話と関係する標準を含むが、この文書はより広
い範囲を意図します。それ故に、ＰＳＴＮのような、特定の体系との競争や、
特定のアプリケーションに焦点を合わすのは、範囲外です。さらに、政府の
規制や法律をサポートする要求条件の仕様はこの文書の範囲外です。ＩＥＴ
Ｆとその作業班の焦点はインターネット体系のための技術的位置です。
Another item that is not in scope of this document is mandating
acceptance and support of the requirements presented in this
document. There is an expectation that business contracts, (e.g.,
Service Level Agreements), will be used to satisfy those requirements
that apply to service providers. Absence of an SLA implies best
effort service is provided.
この文書の範囲外のもう１つの項目は、この文書で示された要求条件の受入
れとサポートの義務化です。サービスプロバイダに当てはまる要求条件を満
たすビジネス契約（例えば、サービスレベル協定）が使われるであろうとい
う期待があります。ＳＬＡがなければ最良努力の供給を暗示します。
3. General Requirements
3. 一般的要求条件
These are general requirements that apply to authorized emergency
telecommunications service. The first requirement is presented as a
conditional one since not all applications use or are reliant on
signaling.
これらは公認緊急通信サービスに当てはまる一般的な要求条件です。全ての
アプリケーションが信号を使用するか信号に依存する、のではないので、最
初の要求条件は条件付きとして提示されます。
1) Signaling
1) 信号
IF signaling is to be used to convey the state or existence of
emergency, then signaling mechanism(s) MUST exist to carry
applicable labels.
もし信号が緊急の状態や存在を伝達するために使われるなら、アプリケー
ションラベルを送る信号メカニズムが存在しなくてはなりません(MUST)。
2) Labels
2) ラベル
Labels may exist in various forms at different layers. They might
be carried as part of signaling, and/or as part of the header of a
data packet. Labels from different layers are NOT required to be
the same, but MAY be related to each other.
異なる層で種々の形式でラベルが存在するかもしれません。それらは信号
の一部やデータパケットのヘッダの一部で運ばれるかもしれません。異な
る層のラベルが同じであるように要求されませんが、お互いと関係がある
かもしれません(MAY)。
3) Policy
3) ポリシ
Policy MUST be kept separate from label(s). This topic has
generated a fair amount of debate, and so we provide additional
guidance from the following:
ポリシがラベルと独立でなければなりません(MUST)。この話題は公正量の
議論を生み出しました、それで我々は次の追加ガイダンスを供給します：
A set of labels may be defined as being related to each other.
Characteristics (e.g., drop precedence) may also be attributed to
these labels. [11] is an example of a related set of labels based
on a specific characteristic.
ラベル集合がお互いに関連して定義されるかもしれません。特徴（例えば、
廃棄優先）がこれらのラベルの属性かもしれません。[11]は特定の特徴に
基づく関連ラベル集合の例です。
However, the mechanisms used to achieve a stated characteristic
MUST NOT be stated in the definition of a label. Local policy
determines mechanism(s) used to achieve or support a specific
characteristic. This allows for the possibility of different
mechanisms to achieve the same stated characteristic.
しかしながら、述べた特徴を成し遂げるために使うメカニズムはラベルの
定義で述べられてはなりません(MUST NOT)。ローカルポリシが、特定の特
徴を成し遂げるかサポートする、メカニズムを決定します。これは同じ機
能を成し遂げる異なるメカニズムの可能性を考慮します。
The interaction between unrelated labels MUST NOT be embedded
within the definition of a label. Local policy states the actions
(if any) to be taken if unrelated labeled traffic merges at a
node.
無関係なラベル間の相互作用はラベルの定義の中に埋め込まれていてはな
りません(MUST NOT)。ローカルポリシが、もし無関係ラベルのトラフィッ
クがノードで合流した場合に、（もしあれば）行うべき行動を述べます。
Finally, labels may have additional characteristics added to them
as a result of local policy.
最終的に、ラベルがローカルポリシにより追加の特徴を持つかもしれませ
ん。
4) Network Functionality
4) ネットワーク機能
Functionality to support a better than best effort SHOULD focus on
probability versus guarantees. Probability can be realized in
terms of reduced probability of packet loss, and/or minimal
jitter, and/or minimal end-to-end delay. There is NO requirement
that a better than best effort functionality MUST exist. There is
NO requirement that if a better than best effort functionality
exists then it must be ubiquitous between end users.
最善努力より上をサポートする機能は可能性と保証に焦点を合わせるべき
です(SHOULD)。可能性がパケット損失の減少とジッタの最小化とエンドエ
ンド遅延の最小化に関して実現できます。最善努力機能より上が存在しな
くてはならない(MUST)という要求条件がありません(NO)。最善努力機能よ
り上が存在してもそれがユーザ間に遍在しなくてはならないという要求条
件がありません(NO)。
3.1. General Security Related Requirements
3.1. 一般的セキュリティ関連要求条件
The following are security related requirements that emerge given the
requirements 1 through 4 above.
次は要求条件１から４までの元で出現するセキュリティ関連要求条件です。
5) Authorization
5) 認可
Authorization is a method of validating that a user or some
traffic is allowed by policy to use a particular service offering.
認可はユーザや何かのトラヒックが、ポリシにより特定のサービスを使用
するのを許されるかどうか検証する手段です。
Mechanisms must be implemented so that only authorized users have
access to emergency telecommunications services. Any mechanism
for providing such authorization beyond closed private networks
SHOULD meet IETF Security Area criterion (e.g., clear-text
passwords would not generally be acceptable). Authorization
protects network resources from excessive use, from abuse, and
might also support billing and accounting for the offered service.
ただ公認ユーザだけが緊急通信サービスにアクセス出来るように、メカニ
ズムが実装されなくてはなりません。閉じた私的網以外でこのような認可
を供給するメカニズムはＩＥＴＦセキュリティエリア基準（例えば、クリ
アテキストパスワードが一般に許容できない）を満たすべきです(SHOULD)。
認可がネットワーク資源の極端な使用や乱用やから守り、そして供給サー
ビスの料金請求をサポートするかもしれません。
Such authorization mechanisms SHOULD be flexible enough to provide
various levels of restriction and authorization depending on the
expectations of a particular service or customer.
このような認可メカニズムは、特定のサービスや顧客の期待に依存した、
様々なレベルの制限と認可を供給するさけの柔軟性があるべきです(SHOULD)。
6) Integrity & Authentication
6) 完全性＆認証
In practice, authentication and integrity for IP based
communications are generally bound within a single mechanism, even
though conceptually they are different. Authentication ensures
that the user or traffic is who it claims to be. Integrity offers
assurance that unauthorized modifications to objects can be
detected.
実際のところ、認証と完全性は概念は異なっているが、ＩＰベースの通信
で一般にひとつのメカニズムに結合されています。認証がユーザやトラ
フィックが誰でかを保証します。完全性がオブジェクトへの無許可の修正
が検出される保証を提供します。
Authorized emergency traffic needs to have reduced risk of adverse
impact from denial of service. This implies a need to ensure
integrity of the authorized emergency network traffic. It should
be noted, though, that mechanisms used to ensure integrity can
also be subject to Denial of Service attacks.
公認の緊急トラフィックがサービス妨害攻撃の影響のリスクを減らす必要
があります。これは公認の緊急ネットワークトラフィックの完全性を保証
の必要性を暗示します。完全性の保障をするメカニズム自体がサービス妨
害攻撃の対象となる事に気づくべきです。
Users of emergency network services SHOULD consider deploying
end-to-end integrity and authentication, rather than relying on
services that might be offered by any single provider of emergency
network services. Users SHOULD also carefully consider which
application-layer security services might be appropriate to use.
緊急ネットワークサービスのユーザは、緊急ネットワークサービスの１プ
ロバイダのサービスに頼るより、エンドエンド完全性と認証の配置を考え
るべきです(SHOULD)。ユーザが慎重にどのアプリケーション層のセキュリ
ティサービスを使うのに適切であるか考えるべきです(SHOULD)。
7) Confidentiality
7) 機密性
Some emergency communications might have a requirement that they
not be susceptible to interception or viewing by others, due to
the sensitive and urgent nature of emergency response activities.
An emergency telecommunications service MAY offer options to
provide confidentiality for certain authorized user traffic.
ある緊急通信は、緊急応答活動の敏感なで緊急な性質のために、他の人た
ちからの妨害や盗聴の可能性がないという要求条件があるかもしれません。
緊急通信サービスがある特定の公認のユーザートラフィックに機密性を提
供する選択をするかもしれません(MAY)。
Consistent with other IETF standards and the Internet
Architecture, this document recommends that IEPREP users SHOULD
deploy end-to-end security mechanisms, rather than rely on
security services that might be offered by a single network
operator. IEPREP users SHOULD carefully consider security
alternatives (e.g., PGP, TLS, IPsec transport-mode) at different
layers (e.g., Application Layer, Session Layer, Transport Layer)
of the Internet Architecture before deployment.
他のＩＥＴＦ標準とインターネット体系と整合して、この文書はＩＥＰＲ
ＥＰユーザがネットワークオペレータの供給するかもしれないセキュリティ
サービスに依存するよりエンドエンドセキュリティ機構を実装するべき
(SHOULD)ことを勧めます。ＩＥＰＲＥＰユーザが慎重に開発前にインター
ネット体系の他の層（例えば、アプリケーションレイヤ、セッションレイ
ヤ、トランスポートレイヤ）のセキュリティ（つまり、ＰＧＰやＴＬＳや
ＩＰｓｅｃトランスポートモード）を考えるべきです(SHOULD)。
4. Issues
4. 問題
This section presents issues that arise in considering solutions for
the requirements that have been defined for ETS. This section does
not specify solutions nor is it to be confused with requirements.
Subsequent documents that articulate a more specific set of
requirements for a particular service may make a statement about the
following issues.
この章はＥＴＳで定義された要求条件に関する解決策を考える際に起こる問
題を提出します。この章は解決策を指定せず、要求条件と混同しないで下さ
い。特定のサービスのより特定の要求条件を明示する後の文書が次の問題の
宣言をするかもしれません。
1) Accounting
1) 課金
Accounting represents a method of tracking actual usage of a
service. We assume that the usage of any service better than best
effort will be tracked and subsequently billed to the user.
Accounting is not addressed as a general requirement for ETS.
However, solutions used to realize ETS should not preclude an
accounting mechanism.
課金がサービスの実際の使用を追跡する方法を表します。我々は最善努力
より良いサービスの使用を追跡し、その後ユーザに請求すると想定します。
課金がＥＴＳのための一般的な要求条件とは扱われません。しかしながら、
ＥＴＳを実現するために使われた解決策は課金機構を妨げるべきではあり
ません。
2) Admission Control
2) 認可制御
The requirements of section 3 discuss labels and security. Those
developing solutions should understand that the ability labels
provide to distinguish emergency flows does not create an ability
to selectively admit flows. Admission control as it is commonly
understood in circuit-switched networks is not present in IP-based
networks, and schemes which presume the ability to selectively
admit flows when resources are scarce will fail outside of very
controlled environments. In cases where emergency related flows
occur outside of controlled environments, the development of
technologies based on admission control is not recommended as the
foundation of emergency services.
３章の要求条件はラベルとセキュリティを論じます。解決策を開発する人
たちは緊急フローを区別するためのラベル能力が選択的にフローを認める
能力を作らないことを理解するべきです。回線交換網で一般に認識される
認可制御はＩＰベースのネットワークでは存在していません、そして、資
源欠乏時に選択的にフローを認める能力を予想する案は、完全に制御され
た環境以外では失敗するでしょう。制御された環境の外に緊急関連フロー
が出る場合、許可制御に基づいた技術の開発は緊急サービスの基礎として
推薦されません。
3) Digital Signatures
3) ディジタル署名
Verification of digital signatures is computationally expensive.
If an operator acts upon a label and hence needs to verify the
authenticity of the label, then there is a potential denial-of-
service attack on the entity performing the authentication. The
DoS attack works by flooding the entity performing the
authentication with invalid (i.e., not authentic) labelled
information, causing the victim to spend excessive amounts of
computing resources on signature validation. Even though the
invalid information might get discarded after the signature
validation fails, the adversary has already forced the victim to
expend significant amounts of computing resource. Accordingly,
any system requiring such validation SHOULD define operational and
protocol measures to reduce the vulnerability to such a DoS
attack.
ディジタル署名の検証は計算量的に高価です。もしオペレータがラベルに
対して行動を起こし、それ故ラベルの信憑性を確かめる必要があるなら、
エンティティ認証を行うことについて「サービス妨害」攻撃の可能性があ
ります。サービス妨害攻撃は不正（すなわち、正しくない）ラベル情報で
認証を行うエンティティを水浸しにすることで作動し、犠牲者の計算資源
の極端な量を署名検証に使わせます。無効な情報は署名検証失敗後に捨て
られるかもしれないけれども、敵はすでに犠牲者の重要な計算資源の消費
を強いました。したがって、このような検証を必要としているシステムは、
このようなサービス妨害攻撃の脆弱性を減らすため、使用可能なプロトコ
ル計量を定義するべきです(SHOULD)。
5. Related Work
5. 関連した仕事
RFC 3487 describes requirements for resource priority mechanisms for
the Session Initiation Protocol [8]. The requirements specified in
that RFC pertain to a specific application level protocol. In
contrast, the requirements of this document are a generalization that
are not application specific. From this blueprint (acting as a
guideline), more specific requirements may be described in future
documents.
ＲＦＣ３４８７はセッション開始プロトコル[8]のために資源優先メカニズム
の要求条件を記述します。そのRFCで指定された要求条件は特定のアプリケー
ションレベルプロトコルに関係があります。それと対照的に、この文書の要
求条件はアプリケーション固有でない一般論です。この（ガイドラインの役
を務めている）青写真から、より特定の要求条件が将来の文書で記述される
かもしれません。
6. Security Considerations
6. セキュリティの考察
Security in terms of requirements is discussed sections 3.1 and 4.
セキュリティの要求条件に関して３.１章と４章で論じられました。
7. References
7. 参考文献
7.1. Normative Reference
7.1. 参照する参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
7.2. 有益な参考文献
[2] ANSI, "Signaling System No. 7(SS7) "High Probability of
Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999).
[3] "Description of an International Emergency Preference Scheme
(IEPS)", ITU-T Recommendation E.106 March, 2000.
[4] "Description for an International Emergency Multimedia Service",
ITU Draft Recommendation F.706, February, 2002.
[5] "Call Priority Designation for H.323 Calls", ITU Recommendation
H.460.4, November, 2002.
[6] ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recommendation, I.255.3, July, 1990.
[7] U.S. National Communications System: http://www.ncs.gov
[8] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, February
2003.
[9] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for
Emergency Telecommunications Service", RFC 3690, February 2004.
[10] Tada, N., et. al., "IAA System (I Am Alive): The Experiences of
the Internet Disaster Drills", Proceedings of INET-2000, June.
[11] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
8. Authors' Addresses
8. 著者のアドレス
Ken Carlberg
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
EMail: k.carlberg@cs.ucl.ac.uk
Ran Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
95051 USA
EMail: rja@extremenetworks.com
9. Full Copyright Statement
9. 著作権表示全文
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００４）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。