Network Working Group H. Schulzrinne
Request for Comments: 3487 Columbia University
Category: Informational February 2003
Requirements for Resource Priority Mechanisms for the
Session Initiation Protocol (SIP)
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP).
この文書では、セッション開始プロトコル（SIP）を使用して、防災通信用の回線交換ネットワーク、エンドシステムおよびプロキシリソースへのアクセスを優先順位付けするための要件をまとめたものです。
Table of Contents
目次
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Resources ................................................... 4
4. Network Topologies .......................................... 5
5. Network Models .............................................. 6
6. Relationship to Emergency Call Services ..................... 7
7. SIP Call Routing ............................................ 8
8. Policy and Mechanism ........................................ 8
9. Requirements ................................................ 9
10. Security Requirements ....................................... 12
10.1 Authentication and Authorization ....................... 12
10.2 Confidentiality and Integrity .......................... 13
10.3 Anonymity .............................................. 14
10.4 Denial-of-Service Attacks .............................. 14
11. Security Considerations ..................................... 15
12. Acknowledgements ............................................ 15
13. Normative References ........................................ 15
14. Informative References ...................................... 15
15. Author's Address ............................................ 16
16. Full Copyright Statement .................................... 17
During emergencies, communications resources including telephone circuits, IP bandwidth and gateways between the circuit-switched and IP networks may become congested. Congestion can occur due to heavy usage, loss of resources caused by the natural or man-made disaster and attacks on the network during man-made emergencies. This congestion may make it difficult for persons charged with emergency assistance, recovery or law enforcement to coordinate their efforts. As IP networks become part of converged or hybrid networks along with public and private circuit-switched (telephone) networks, it becomes necessary to ensure that these networks can assist during such emergencies.
緊急時に、回線交換とIPネットワークとの間の電話回線、IP帯域幅及びゲートウェイを含む通信リソースが混雑してもよいです。輻輳が原因多用、人工緊急時に、自然や人災やネットワークへの攻撃によって引き起こされる資源の損失に発生する可能性があります。この混雑は彼らの努力を調整するために緊急支援、復旧や法執行機関で起訴者のための、それが困難になることがあります。 IPネットワークは、パブリックおよびプライベート回線交換（電話）ネットワークと共に収束またはハイブリッドネットワークの一部になるように、これらのネットワークは、このような緊急時に支援することができることを確実にするために必要となります。
There are many IP-based services that can assist during emergencies. This memo only covers requirements for real-time communications applications involving the Session Initiation Protocol (SIP) [1], including voice-over-IP, multimedia conferencing and instant messaging/presence.
緊急時に支援することができ、多くのIPベースのサービスがあります。このメモは、セッション開始プロトコル（SIP）を含むリアルタイム通信アプリケーションのための要件をカバーして、[1]、ボイスオーバーIP、マルチメディア会議、インスタント・メッセージング/プレゼンスを含みます。
This document takes no position as to which mode of communication is preferred during an emergency, as such discussion appears to be of little practical value. Based on past experience, real-time communications is likely to be an important component of any overall suite of applications, particularly for coordination of emergency-related efforts.
そのような議論はほとんど実用的価値があると表示されるこの文書は、通信のモードは、緊急時に好適であるとして先のない位置を取りません。過去の経験に基づいて、リアルタイム通信は、特に緊急関連の取り組みの調整のために、アプリケーションのいずれかの全体的な一連の重要な構成要素である可能性が高いです。
As we will describe in detail below, such Session Initiation Protocol (SIP) [1] applications involve at least five different resources that may become scarce and congested during emergencies. In order to improve emergency response, it may become necessary to prioritize access to such resources during periods of emergency-induced resource scarcity. We call this "resource prioritization".
我々は、以下に詳細に説明するように、このようなセッション開始プロトコル（SIP）[1]アプリケーションは、緊急時に希少で混雑になることがあり、少なくとも5つの異なるリソースを含みます。緊急時の対応を向上させるためには、緊急誘発性資源不足の期間中、このようなリソースへのアクセスを優先させる必要になることがあります。私たちは、この「リソースの優先順位付け」と呼びます。
This document describes requirements rather than possible existing or new protocol features. Although it is scoped to deal with SIP-based applications, this should not be taken to imply that mechanisms have to be SIP protocol features such as header fields, methods or URI parameters.
この文書では、要件ではなく、可能な既存または新しいプロトコルの機能について説明します。 SIPベースのアプリケーションに対処するためにスコープされているが、これは機構は、ヘッダフィールド、メソッドまたはURIパラメータとしてSIPプロトコル機能でなければならないことを意味すると解釈されるべきではありません。
The document is organized as follows. In Section 2, we explain core technical terms and acronyms that are used throughout the document. Section 3 describes the five types of resources that may be subject to resource prioritization. Section 4 enumerates four network hybrids that determine which of these resources are relevant. Since the design choices may be constrained by the assumptions placed on the IP network, Section 5 attempts to classify networks into categories according to the restrictions placed on modifications and traffic classes.
次のように文書が編成されています。第2節では、文書全体で使用されているコア技術用語と略語を説明します。第3節では、優先順位付けをリソースへの対象となることがあり、リソースの5つのタイプについて説明します。第4節では、これらのリソースのどれが関連しているかを決定4つのネットワークハイブリッドを列挙します。設計選択は、IPネットワーク上に配置された仮定によって拘束することができるので、第5の試みは、修正およびトラフィッククラスに設定された制限に応じてカテゴリにネットワークを分類します。
Since this is a major source of confusion due to similar names, Section 6 attempts to distinguish emergency call services placed by civilians from the topic of this document.
これが原因類似した名前は、この文書のトピックから民間人によって置かれた緊急コールサービスを区別するための第6の試みへの混乱の主要な源であるからです。
Request routing is a core component of SIP, covered in Section 7.
リクエストルーティングはセクション7で覆われたSIPのコアコンポーネントです。
Providing resource priority entails complex implementation choices, so that a single priority scheme leads to a set of algorithms that manage queues, resource consumption and resource usage of existing calls. Even within a single administrative domain, the combination of mechanisms is likely to vary. Since it will also depend on the interaction of different policies, it appears inappropriate to have SIP applications specify the precise mechanisms. Section 8 discusses the call-by-value (specification of mechanisms) and call-by-reference (invoke labeled policy) distinction.
単一優先順位方式は、キュー、資源消費と既存のコールのリソース使用量を管理するアルゴリズムのセットにつながるように、リソースの優先度を提供することは、複雑な実装の選択を伴います。でも、単一の管理ドメイン内で、機構の組合せは異なる可能性があります。それはまた別のポリシーとの相互作用に依存しますので、SIPアプリケーションが正確なメカニズムを指定していすることは不適切表示されます。セクション8は、コールバイバリュー（メカニズムの仕様）およびコールバイリファレンス（標識されたポリシーを呼び出す）区別を論じています。
Based on these discussions, Section 9 summarizes some general requirements that try to achieve generality and feature-transparency across hybrid networks.
これらの議論を踏まえ、第9節は、ハイブリッドネットワークを介して一般性と機能・透明性を達成しようとするいくつかの一般的な要件をまとめたもの。
The most challenging component of resource prioritization is likely to be security (Section 10). Without adequate security mechanisms, resource priority may cause more harm than good, so that the section attempts to enumerate some of the specific threats present when resource prioritization is being employed.
リソースの優先順位付けの最も挑戦的なコンポーネントは、セキュリティ（第10節）である可能性が高いです。リソースの優先順位付けが採用されているときにセクションが存在する特定の脅威のいくつかを列挙しようとするように、適切なセキュリティメカニズムがなければ、リソースの優先順位は、良いよりも害を引き起こす可能性があります。
CSN: Circuit-switched network, encompassing both private (closed) networks and the public switched telephone network (PSTN).
CSN：プライベート（閉じた状態）ネットワークの両方を網羅する、ネットワークの回線交換と公衆交換電話網（PSTN）。
ETS: Emergency telecommunications service, identifying a communications service to be used during large-scale emergencies that allows authorized individuals to communicate. Such communication may reach end points either within a closed network or any endpoint on the CSN or the Internet. The communication service may use voice, video, text or other multimedia streams.
ETS：緊急通信サービス、許可された個人が通信することを可能にする大規模な緊急事態の際に使用される通信サービスを識別する。そのような通信は、閉じたネットワーク内またはCSNまたはインターネット上の任意のエンドポイントのいずれかのエンドポイントに到達することができます。通信サービスは、音声、ビデオ、テキストまたは他のマルチメディアストリームを使用することができます。
Request: In this document, we define "request" as any SIP request. This includes call setup requests, instant message requests and event notification requests.
要求：この文書では、我々はすべてのSIP要求として「要求」を定義します。これは、呼設定要求、インスタントメッセージの要求とイベント通知要求を含んでいます。
Prioritized access to at least five resource types may be useful:
少なくとも5つのリソースタイプへのアクセスを優先順位付けすることは有用である可能性があります。
Gateway resources: The number of channels (trunks) on a CSN gateway is finite. Resource prioritization may prioritize access to these channels, by priority queuing or preemption.
ゲートウェイリソース：CSNゲートウェイのチャネルの数（トランク）は有限です。リソースの優先順位付けは、プライオリティキューイングやプリエンプションによって、これらのチャンネルへのアクセスに優先順位をつけることができます。
CSN resources: Resources in the CSN itself, away from the access gateway, may be congested. This is the domain of traditional resource prioritization mechanisms such as MLPP and GETS, where circuits are granted to ETS communications based on queuing priority or preemption (if allowed by local telecommunication regulatory policy and local administrative procedures). A gateway may also use alternate routing (Section 8) to increase the probability of call completion.
CSNの資源：CSN自体内のリソースは、離れたアクセスゲートウェイから、混雑することができます。これは、回路がキューイング優先度またはプリエンプションに基づいて、ETS通信（ローカル通信規制政策とローカル管理手順によって許可されている場合）に付与されMLPPとGETS、などの伝統的なリソースの優先順位付けメカニズムのドメインです。ゲートウェイは、呼完了の確率を増加させるために代替ルーティング（セクション8）を使用することができます。
Specifying CSN behavior is beyond the scope of this document, but as noted below, a central requirement is to be able to invoke all such behaviors from an IP endpoint.
CSNの動作を指定すると、この文書の範囲外であるが、以下のように、中央の要件は、IPエンドポイントからのすべてのこのような行動を呼び出すことができるようになります。
IP network resources: SIP may initiate voice and multimedia sessions. In many cases, audio and video streams are inelastic and have tight delay and loss requirements. Under conditions of IP network overload, emergency services applications may not be able to obtain sufficient bandwidth in any network. When there are insufficient network resources for all users and it is not practical to simply add more resources, quality of service management is necessary to solve this problem. This is orthogonal to SIP, out of the scope for SIP, and as such these requirements will be discussed in another document.
IPネットワークのリソース：SIPは、音声およびマルチメディアセッションを開始することができます。多くの場合、オーディオおよびビデオストリームは非弾性であり、タイトな遅延や損失の要件があります。 IPネットワークの過負荷の条件では、緊急サービス・アプリケーションは、任意のネットワークに十分な帯域幅を得ることができない場合があります。そこにすべてのユーザーのための十分なネットワークリソースであり、単により多くのリソースを追加することは現実的ではない場合は、サービス管理の品質は、この問題を解決する必要があります。これは、SIPの範囲外、SIPに直交し、かつそのようなこれらの要件は、別の文書で説明されるように。
Bandwidth used for SIP signaling itself may be subject to prioritization.
自身をSIPシグナリングに使用される帯域幅は、優先順位付けの対象とすることができます。
Receiving end system resources: End systems may include automatic call distribution systems (ACDs) or media servers as well as traditional telephone-like devices. Gateways are also end systems, but have been discussed earlier.
エンドシステムリソースを受信：エンド・システムには、自動呼分配システム（ACDを）またはメディアサーバーとしてだけでなく、従来の電話のようなデバイスを含むことができます。ゲートウェイは、エンドシステムですが、先に議論されています。
Since the receiving end system can only manage a finite number of sessions, a prioritized call may need to preempt an existing call or indicate to the callee that a high-priority call is waiting. (The precise user agent behavior is beyond the scope of this document and considered a matter of policy and implementation.)
受信側システムは、セッションのみの有限数を管理することができるので、優先順位呼び出しが既存のコールを先取りする必要があるか、優先順位の高いコールが待機している呼び出し先に示すことができます。 （正確なユーザエージェントの動作は、このドキュメントの範囲を超えて、政策と実施の問題を検討しました。）
Such terminating services may be needed to avoid overloading, say, an emergency coordination center. However, other approaches beyond prioritization, e.g., random request dropping by geographic origin, need to be employed if the number of prioritized calls exceeds the terminating capacity. Such approaches are beyond the scope of this memo.
このような終端サービスは、たとえば、過負荷に緊急調整センターを回避するために必要な場合があります。しかし、優先順位付け、地理的起源によって、例えば、ランダムな要求滴下以外の他のアプローチは、優先呼の数が終端容量を超えた場合に使用される必要があります。このようなアプローチは、このメモの範囲を超えています。
SIP proxy resources: While SIP proxies often have large request handling capacities, their capacity is likely to be smaller than their access network bandwidth. (This is true in particular since different SIP requests consume vastly different amounts of proxy computational resources, depending on whether they invoke external services, sip-cgi [2] and CPL [3] scripts, etc. Thus, avoiding proxy overload by restricting access bandwidth is likely to lead to inefficient utilization of the proxy.) Therefore, some types of proxies may need to silently drop selected SIP requests under overload, reject requests, with overload indication or provide multiple queues with different drop and scheduling priorities for different types of SIP requests. However, this is strictly an implementation issue and does not appear to influence the protocol requirements nor the on-the-wire protocol. Thus, it is out of scope for the protocol requirements discussion pursued here.
SIPプロキシリソース：SIPプロキシは、多くの場合、大規模な要求処理能力を有するが、その能力は、そのアクセスネットワークの帯域幅よりも小さくなる可能性があります。 （これは、アクセスを制限することによって、プロキシの過負荷を避け、したがって、[3]スクリプトなど異なるSIPリクエストは、SIP-CGI、彼らは外部サービスを呼び出すかどうかに応じて、プロキシの計算資源の非常に異なる量を消費するので、特に真実である[2]とCPL帯域幅は、プロキシの非効率的な利用につながる可能性が高いです。）ので、プロキシのいくつかの種類が静かに、過負荷の下で選択されたSIP要求をドロップする要求を拒否、過負荷表示またはの種類ごとに異なるドロップとスケジューリングの優先順位で複数のキューを提供する必要があるかもしれませんSIPリクエスト。しかし、これは厳密には実装上の問題であり、プロトコル要件もオン・ワイヤープロトコルに影響を与えるように表示されません。したがって、それはここ追求プロトコル要件の議論の範囲外です。
Responses should naturally receive the same treatment as the corresponding request. Responses already have to be securely mapped to requests, so this requirement does not pose a significant burden. Since proxies often do not maintain call state, it is not generally feasible to assign elevated priority to requests originating from a lower-privileged callee back to the higher-privileged caller.
応答は、自然に対応する要求と同じ処理を受けるべきです。応答は、すでにしっかり要求にマップする必要があり、したがって、この要件は、大きな負担をもたらすことはありません。プロキシは、多くの場合、通話状態を維持していないので、一般的に背の高い特権呼び出し元に低い特権呼び出し先から発信要求に高い優先順位を割り当てることは現実的ではありません。
There is no requirement that a single mechanism be used for all five resources.
単一のメカニズムは、5つのすべてのリソースのために使用される必要はありません。
We consider four types of combinations of IP and circuit-switched networks.
私たちは、IPの組み合わせと回線交換網の4種類を検討してください。
IP end-to-end: Both request originator and destination are on an IP network, without intervening CSN-IP gateways. Here, any SIP request could be subject to prioritization.
IPのエンドツーエンド：要求元と宛先の両方CSN-IPゲートウェイを介在せずに、IPネットワーク上にあります。ここでは、任意のSIPリクエストは、優先順位付けを受ける可能性があります。
IP-to-CSN (IP at the start): The request originator is in the IP network, while the callee is in the CSN. Clearly, this model only applies to SIP-originated phone calls, not generic SIP requests such as those supporting instant messaging services.
IPツーCSN（開始時IP）：被呼者がCSNにある間、要求元は、IPネットワークです。明らかに、このモデルは唯一のSIP発信電話ではなく、このようなインスタントメッセージングサービスをサポートするような一般的なSIPリクエストに適用されます。
CSN-to-IP (IP at the end): A call originates in the CSN and terminates, via an Internet telephony gateway, in the IP network.
CSNとIP（端におけるIP）呼がIPネットワークでは、インターネット電話ゲートウェイを介して、CSNと終了に起因します。
CSN-IP-CSN (IP bridging): This is a concatenation of the two previous ones. It is worth calling out specifically to note that the two CSN sides may use different signaling protocols. Also, the originating CSN endpoint and the gateway to the IP network may not know the nature of the terminating CSN. Thus, encapsulation of originating CSN information is insufficient.
CSN-IP-CSN（IPブリッジング）：これは、前の2つのものを連結したものです。これは、2つのCSN側面が異なるシグナリングプロトコルを使用することができることに注意することは、具体的呼び出す価値があります。また、元のCSNエンドポイントとIPネットワークへのゲートウェイは終了CSNの本質を知らないかもしれません。したがって、発信CSN情報のカプセル化が不十分です。
The bridging model (IP-CSN-IP) can be treated as the concatenation of the IP-to-CSN and CSN-to-IP cases.
ブリッジングモデル（IP-CSN-IP）は、IPとCSNとCSNとIPケースの連結として扱うことができます。
It is worth emphasizing that CSN-to-IP gateways are unlikely to know whether the final destination is in the IP network, the CSN or, via SIP forking, in both.
これは、両方で、フォークSIP経由して、ゲートウェイは最終目的地は、IPネットワーク、CSNかであるかを知っている可能性が低いCAN-TO-IPという強調する価値があります。
These models differ in the type of controllable resources, identified as gateway, CSN, IP network resources, proxy and receiver. Items marked as (x) are beyond the scope of this document.
これらのモデルは、ゲートウェイ、CSN、IPネットワークリソース、プロキシおよび受信機として識別された制御可能なリソースの種類が異なります。 （x）はとしてマークされたアイテムは、このドキュメントの範囲を超えています。
Topology Gateway CSN IP proxy receiver
_________________________________________________
IP-end-to-end (x) (x) x
IP-to-CSN x x (x) (x) (x)
CSN-to-IP x x (x) (x) x
CSN-IP-CSN x x (x) (x) (x)
There are at least four IP network models that influence the requirements for resource priority. Each model inherits the restrictions of the model above it.
リソース優先順位の要件に影響を与える少なくとも4つのIPネットワークのモデルがあります。各モデルは、それ以上のモデルの制限を継承します。
Pre-configured for ETS: In a pre-configured network, an ETS application can use any protocol carried in IP packets and modify the behavior of existing protocols. As an example, if an ETS agency owns the IP network, it can add traffic shaping, scheduling or support for a resource reservation protocol to routers.
ETSのために事前構成：事前構成されたネットワークでは、ETSのアプリケーションがIPパケットで運ばれる任意のプロトコルを使用して、既存のプロトコルの動作を変更することができます。 ETS機関がIPネットワークを所有している場合の例としては、それはルータにリソース予約プロトコルのトラフィックシェーピング、スケジューリングやサポートを追加することができます。
Transparent: In a transparent network, an ETS application can rely on the network to forward all valid IP packets, however, the ETS application cannot modify network elements. Commercial ISP offer transparent networks as long as they do not filter certain types of packets. Networks employing firewalls, NATs and "transparent" proxies are not transparent. Sometimes, these types of networks are also called common-carrier networks since they carry IP packets without concern as to their content.
透明：透明ネットワークでは、ETSのアプリケーションは、すべての有効なIPパケットを転送するためにネットワークに依存することができます、しかし、ETSのアプリケーションは、ネットワーク要素を変更することはできません。商用ISPは限りがパケットの特定の種類をフィルタリングしないように、透明なネットワークを提供します。ファイアウォール、NATのと「透明」プロキシを使用するネットワークは、透明ではありません。彼らは彼らのコンテンツに対する懸念せずにIPパケットを運ぶので、時々、これらのタイプのネットワークは、共通キャリア・ネットワークと呼ばれています。
SIP/RTP transparent: Networks that are SIP/RTP transparent allow users to place and receive SIP calls. The network allows ingress and egress for all valid SIP messages, possibly subject to authentication. Similarly, it allows RTP media streams in both directions. However, it may block, in either inbound or outbound direction, other protocols such as RSVP or it may disallow non-zero DSCPs. There are many degrees of SIP/RTP transparency, e.g., depending on whether firewalls require inspection of SDP content, thus precluding end-to-end encryption of certain SIP message bodies, or whether only outbound calls are allowed. Many firewalled corporate networks and semi-public access networks such as in hotels are likely to fall into this category.
透明SIP / RTP：SIP / RTP透明でありNetworksは、ユーザーがSIPコールを配置して受け取ることができます。ネットワークは、認証におそらく対象となるすべての有効なSIPメッセージのための入力および出力を可能にします。同様に、両方向のRTPメディアストリームを可能にします。しかし、それは、インバウンドまたはアウトバウンドいずれかの方向に、ブロック例えばRSVPのような他のプロトコルまたはそれが非ゼロのDSCPを禁止してもよいです。 SIP / RTP透明の何度は、ファイアウォールは、このようにのみ発信コールが許可されるかどうか、特定のSIPメッセージボディのエンド・ツー・エンドの暗号化を排除、または、SDPの内容の検査を必要とするかどうかに応じて、例えば、存在します。なホテルのような多くのファイアウォール、企業ネットワークとセミパブリックアクセスネットワークは、このカテゴリーに入る可能性があります。
Restricted SIP networks: In restricted SIP networks, users may be restricted to particular SIP applications and cannot add SIP protocol elements such as header fields or use SIP methods beyond a prescribed set. It appears likely that 3GPP/3GPP2 networks will fall into this category, at least initially.
SIPネットワーク制限：制限されたSIPネットワークでは、ユーザは、特定のSIPアプリケーションに制限されてもよく、そのようなヘッダフィールドとしてSIPプロトコル要素を追加したり、所定の設定を超えてSIPメソッドを使用することはできません。 3GPP / 3GPP2ネットワークは、少なくとも最初は、このカテゴリーに分類される可能性が高い表示されます。
A separate and distinct problem are SIP networks that administratively prohibit or fail to configure access to special access numbers, e.g., the 710 area code used by GETS. Such operational failures are beyond the reach of a protocol specification.
分離した別個の問題が管理上禁止または特別なアクセス番号へのアクセスを構成することができないSIPネットワークであり、例えば、710によって使用されるエリアコードを取得します。このような動作不良は、プロトコル仕様の範囲を超えています。
It appears desirable that ETS users can employ the broadest possible set of networks during an emergency. Thus, it appears preferable that protocol enhancements work at least in SIP/RTP transparent networks and are added explicitly to restricted SIP networks.
ETSのユーザーが緊急時にネットワークの可能な限り広いセットを採用することが望ましい表示されます。これにより、プロトコルの拡張は、少なくともSIP / RTP透明ネットワークで動作し、制限されたSIPネットワークに明示的に追加されることが好ましい見えます。
The existing GETS system relies on a transparent network, allowing use from most unmodified telephones, while MLPP systems are typically pre-configured.
既存のGETSシステムは、MLPPシステムは、典型的には事前に構成されているが、最も修飾されていない電話の使用を可能にする、透明なネットワークに依存しています。
The resource priority mechanisms are used to have selected individuals place calls with elevated priority during times when the network is suffering from a shortage of resources. Generally, calls for emergency help placed by non-officials (e.g., "911" and "112" calls) do not need resource priority under normal circumstances. If such emergency calls are placed during emergency-induced network resource shortages, the call identifier itself is sufficient to identify the emergency nature of the call. Adding an indication of resource priority may be less appropriate, as this would require that all such calls carry this indicator. Also, it opens another attack mechanism, where non-emergency calls are marked as emergency calls. (If network elements can recognize the request URI as an emergency call, they would not need the resource priority mechanism.)
リソースの優先順位メカニズムは、ネットワークリソースの不足に苦しんでいるときの時間の間に高い優先順位を持つ個人の場所の呼び出しを選択しているために使用されています。一般的に、通常の状況下では、リソースの優先順位を必要としない（例えば、「911」と「112」のコール）非役人によって置かれた緊急援助を求めています。こうした緊急コールが緊急誘発ネットワークリソース不足時に配置されている場合は、コール識別子自体は、コールの緊急性を識別するのに十分です。これは、すべてのそのような呼び出しは、このインジケータを運ぶことを必要とするようにリソース優先順位の指示を追加すると、あまり適切であり得ます。また、非緊急コールは、緊急呼び出しとしてマークされている別の攻撃メカニズムを開きます。 （ネットワーク要素は、緊急呼び出しとしてリクエストURIを認識できる場合は、リソース優先順位メカニズムを必要としません。）
The routing of a SIP request, i.e., the proxies it visits and the UAs it ends up at, may depend on the fact that the SIP request is an ETS request. The set of destinations may be larger or smaller, depending on the SIP request routing policies implemented by proxies. For example, certain gateways may be reserved for ETS use and thus only be reached by labeled SIP requests.
SIP要求のルーティングは、すなわち、それは訪問プロキシとそれに終わるUAは、SIP要求がETS要求であるという事実に依存してもよいです。宛先のセットは、プロキシによって実現SIP要求のルーティングポリシーに応じて、大きくても小さくてもよいです。例えば、特定のゲートウェイはETSの使用のために予約されてもよく、したがってのみ標識SIPリクエストが到達します。
Most priority mechanisms can be roughly categorized by whether they:
最も優先順位のメカニズムは、大別し、それらかどうかによって分類することができます。
o use a priority queue for resource attempts,
Oリソースの試みのためのプライオリティキューを使用し、
o make additional resources available (e.g., via alternate routing (ACR)), or
O（例えば、代替ルーティング（ACR）を経由して）、追加のリソースを利用できるように、または
o preempt existing resource users (e.g., calls.)
Oプリエンプト既存のリソースユーザ（例えば、呼び出し）。
For example, in GETS, alternate routing attempts to use alternate GETS-enabled interexchange carriers (IXC) if it cannot be completed through the first-choice carrier.
例えば、GETSに、代替ルーティングは、それが最初の選択肢のキャリアを介して完了できない場合、代替対応GETSエクスチェンジキャリア（IXC）を使用することを試みます。
Priority mechanisms may also exempt certain calls from network management traffic controls.
優先順位メカニズムは、ネットワーク管理トラフィックのコントロールから特定の呼び出しを免除することがあります。
The choice between these mechanisms depends on the operational needs and characteristics of the network, e.g., on the number of active requests in the system and the fraction of prioritized calls. Generally, if the number of prioritized calls is small compared to the system capacity and the system capacity is large, it is likely that another call will naturally terminate in short order when a higher-priority call arrives. Thus, it is conceivable that the priority indication can cause preemption in some network entities, while elsewhere it just influences whether requests are queued instead of discarded and what queueing policy is being applied.
これらのメカニズム間の選択は、システム内のアクティブな要求の数と、優先呼の画分に、例えば、ネットワークの運用上のニーズ及び特性に依存します。優先呼の数がシステム容量に比べて小さいとシステム容量が大きい場合には、一般に、より高い優先度の呼が到着したときに別のコールが自然短い順に終了する可能性があります。このように、他の場所でそれだけで要求がキューの代わりに破棄され、どのようなキューイングポリシー適用されているかどうかに影響しながら、優先順位の表示は、いくつかのネットワークエンティティにプリエンプションを引き起こす可能性が考えられます。
Some namespaces may inherently imply a preemption policy, while others may be silent on whether preemption is to be used or not, leaving this to local entity policy.
他の人がプリエンプションがローカルエンティティポリシーにこれを残して、使用するか否かについては言及かもしれないが、いくつかの名前空間は、本質的に、プリエンプションポリシーを意味し得ます。
Similarly, the precise relationships between labels, e.g., what fraction of capacity is set aside for each priority level, is also a matter of local policy. This is similar to how differentiated services labels are handled.
同様に、ラベル間の正確な関係は、例えば、容量のどの画分が各優先度レベルのために確保され、また、ローカルポリシーの問題です。これは、ラベルがどのように扱われるか差別化サービスに似ています。
In the PSTN and certain private circuit-switched networks, such as those run by military organizations, calls are marked in various ways to indicate priorities. We call this a "priority scheme".
PSTNと、このような軍事組織によって実行されるような特定の専用回線交換ネットワークでは、コールは、優先順位を示すために、さまざまな方法でマークされています。私たちは、「優先度方式」これを呼び出します。
Below are some requirements for providing a similar feature in a SIP environment; security requirements are discussed in Section 10. We will refer to the feature as a "SIP indication" and to requests carrying such an indication as "labelled requests".
以下は、SIP環境で同様の機能を提供するためのいくつかの要件があります。セキュリティ要件は、私たちは、「SIPの表示」とし、「ラベルの要求」などの指示を運ぶ要求に機能を参照するセクション10で議論されています。
Note: Not all the following requirements are possible to meet at once. They may represent in some case tradeoffs that must be considered by the designer.
注：すべての以下の要件が一度に満たすことが可能です。彼らは、設計者が考慮しなければならないいくつかのケースのトレードオフで表すことができます。
REQ-1: Not specific to one scheme or country: The SIP indication should support existing and future priority schemes. For example, there are currently at least four priority schemes in widespread use: Q.735, also implemented by the U.S. defense telephone network ("DSN" or "Autovon") and NATO, has five levels, the United States GETS (Government Emergency Telecommunications Systems) scheme with implied higher priority and the British Government Telephone Preference Scheme (GTPS) system, which provides three priority levels for receipt of dial tone.
REQ-1：既存および将来の優先順位方式をサポートしている必要がありSIP表示：1つの方式や国に固有のものではありません。例えば、少なくとも4つの優先順位方式が普及し、現在があります。また、米国の防衛電話網（「DSN」または「Autovon」）とNATOによって実装Q.735は、5つのレベルがあり、米国はGETS（政府の緊急時には、暗黙の優先順位が高いとダイヤルトーンを受信するための3つの優先度レベルを提供して英国政府電話優先スキーム（GTPS）システムとの通信システム）方式。
The SIP indication may support these existing CSN priority schemes through the use of different namespaces.
SIP表示は異なる名前空間を使用することによって、これらの既存のCSN優先順位スキームをサポートすることができます。
Private-use namespaces may also be useful for certain applications.
プライベート利用の名前空間は、特定の用途のために有用である可能性があります。
REQ-2: Independent of particular network architecture: The SIP indication should work in the widest variety of SIP-based systems. It should not be restricted to particular operators or types of networks, such as wireless networks or protocol profiles and dialects in certain types of networks. The originator of a SIP request cannot be expected to know what kind of circuit-switched technology is used by the destination gateway.
REQ-2：特定のネットワークアーキテクチャの独立した：SIP指示は、SIPベースのシステムの多種多様で動作すべきです。そのようなネットワークの特定の種類の無線ネットワークまたはプロトコルプロファイルおよび方言などのネットワークの特定のオペレータ又はタイプに限定されるものではありません。 SIPリクエストの発信者は、宛先ゲートウェイで使用されている回線交換技術の種類を知ることは期待できません。
REQ-3: Invisible to network (IP) layer: The SIP indication must be usable in IP networks that are unaware of the enhancement and in SIP/RTP-transparent networks.
REQ-3：ネットワークには見えない（IP）レイヤ：SIP指示は、エンハンスメントの気付かないとSIP / RTP透明ネットワークであるIPネットワークで使用可能でなければなりません。
This requirement can be translated to mean that the request has to be a valid SIP request and that out-of-band signaling is not acceptable.
この要件は、要求が有効SIPリクエストである必要があり、そのアウトオブバンドシグナリングは受け入れられないことを意味すると翻訳することができます。
REQ-4: Mapping of existing schemes: Existing CSN schemes must be translatable to SIP-based systems.
REQ-4：既存の方式のマッピング：既存CSN方式がSIPベースのシステムに翻訳可能でなければなりません。
REQ-5: No loss of information: For the CSN-IP-CSN case, there should be no loss of signaling information caused by translation from CSN signaling SIP and back from SIP to CSN signaling if both circuit-switched networks use the same priority scheme. Loss of information may be unavoidable if the destination CSN uses a different priority scheme from the origin.
REQ-5：情報の損失は：CSN-IP-CSNの場合のために、両方の回線交換ネットワークが同じ優先度を使用する場合、シグナリングCSNに戻っSIPからSIPおよびシグナリングCSNからの翻訳によって引き起こされるシグナリング情報の損失があってはなりませんスキーム。先CSNは、原点とは異なる優先順位スキームを使用する場合、情報の損失が不可避であってもよいです。
One cannot assume that both CSNs are using the same signaling protocol or protocol version, such as ISUP, so that transporting ISUP objects in MIME [4,5] is unlikely to be sufficient.
[4,5] MIMEにISUPオブジェクトを輸送するのに十分なさそうであるように一つは、両方のCSNは、ISUPのように、同一のシグナリングプロトコルまたはプロトコルのバージョンを使用していると仮定することができません。
REQ-6: Extensibility: Any naming scheme specified as part of the SIP indication should allow for future expansion. Expanded naming schemes may be needed as resource priority is applied in additional private networks, or if VoIP-specific priority schemes are defined.
REQ-6：拡張：SIP指示の一部として指定された命名方式は将来の拡張を可能にすべきです。リソースの優先順位は、追加のプライベートネットワークに適用される、またはVoIP固有の優先順位方式が定義されている場合、拡張された命名スキームが必要になることがあります。
REQ-7: Separation of policy and mechanism: The SIP indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should invoke a particular named policy. As an example, instead of specifying that a certain SIP request should be granted queueing priority, not cause preemption, but be restricted to three-minute sessions, the request invokes a certain named policy that may well have those properties in a particular implementation. An IP-to-CSN gateway may need to be aware of the specific actions required for the policy, but the protocol indication itself should not.
REQ-7：ポリシーとメカニズムの分離：このリソースとローカルポリシーの性質に依存する可能性があるとしてSIP指示は、特定の詳細な処理を記述してはなりません。その代わりに、特定の名前のポリシーを呼び出す必要があります。例として、代わりに特定のSIP要求がキューイング優先度を付与する必要があることを指定するのでは、プリエンプションを起こさないが、3分のセッションに制限され、要求はよく、特定の実装では、これらの特性を有することができる特定の名前のポリシーを起動します。 IPツーCSNゲートウェイがポリシーに必要な特定のアクションを認識する必要があるかもしれないが、プロトコルの指示自体はいけません。
Even in the CSN, the same MLPP indication may result in different behavior for different networks.
CSNに、同じMLPP表示は、異なるネットワークの異なる挙動をもたらすことができます。
REQ-8: Method-neutral: The SIP indication chosen should work for any SIP method, not just, say, INVITE.
REQ-8：方法-ニュートラル：選択したSIPの表示は任意のSIPメソッドのために働く必要があり、ちょうど、INVITE、言いません。
REQ-9: Default behavior: Network terminals configured to use a priority scheme may occasionally end up making calls in a network that does not support such a scheme. In those cases, the protocol must support a sensible default behavior that treats the call no worse than a call that did not invoke the priority scheme. Some networks may choose to disallow calls unless they have a suitable priority marking and appropriate authentication. This is a matter of local policy.
REQ-9：デフォルトの動作：たまにこのようなスキームをサポートしていないネットワーク内で通話を発信し終わる可能性優先方式を使用するように構成されたネットワーク端末。これらの例では、プロトコルは、優先順位方式を起動していなかったコールよりも悪くないコールを扱う賢明なデフォルトの動作をサポートしている必要があります。一部のネットワークでは、彼らは、適切な優先順位マーキングし、適切な認証を持っていない限り、通話を拒否することもできます。これは、ローカルポリシーの問題です。
REQ-10: Address-neutral: Any address or URI scheme may be a valid destination and must be usable with the priority scheme. The SIP indication cannot rely on identifying a set of destination addresses or URI schemes for special treatment. This requirement is motivated by existing ETS systems. For example, in GETS and similar systems, the caller can reach any PSTN destination with increased probability of call completion, not just a limited set. (This does not preclude local policy that allows or disallows, say, calls to international numbers for certain users.)
REQ-10：住所中立：任意のアドレスまたはURIスキームが有効な宛先とすることができ、優先順位方式で使用可能でなければなりません。 SIP表示は特別な治療のための宛先アドレスまたはURIスキームのセットを識別するに頼ることはできません。この要件は、既存のETSシステムによって動機付けられています。例えば、取得し、同様のシステムでは、発信者が呼完了の増加確率だけでなく、限られたセットを有する任意のPSTNの宛先に到達することができます。 （これは、特定のユーザーのための国際番号にコールし、たとえば、許可または禁止するローカルポリシーを排除するものではありません。）
Some schemes may have an open set of destinations, such as any valid E.164 number or any valid domestic telephone number, while others may only reach a limited set of destinations.
他の人が宛先のみの限定セットに達する可能性がありながら、いくつかのスキームは、任意の有効なE.164番号または任意の有効な国内の電話番号などの目的地のオープンセットを有することができます。
REQ-11: Identity-independent: The user identity, such as the From header field in SIP, is insufficient to identify the priority level of the request. The same identity can issue non-prioritized requests as well as prioritized ones, with the range of priorities determined by the job function of the caller. The choice of the priority is made based on human judgement, following a set of general rules that are likely to be applied by analogy rather than precise mapping of each condition. For example, a particular circumstance may be considered similarly grave compared to one which is listed explicitly.
REQ-11：アイデンティティに依存しない：ユーザーID、そのようなSIPのヘッダフィールドからASは、要求の優先順位を識別するためには不十分です。同じアイデンティティは、発信者の仕事関数によって決定優先順位の範囲で、非優先の要求だけでなく、優先順位のものを発行することができます。優先順位の選択は、各条件の正確なマッピングではなく、類推によって適用される可能性がある一般的なルールのセットに従って、人間の判断に基づいて行われます。例えば、特定の状況では、明示的に記載されているものと比較して同様に重大と考えることができます。
REQ-12: Independent of network location: While some existing CSN schemes restrict the set of priorities based on the line identity, it is recognized that future IP-based schemes should be flexible enough to avoid such reliance. Instead, a combination of authenticated user identity, user choice and policy determines the request treatment.
REQ-12：ネットワークの場所の独立：いくつかの既存のCSNスキームは、ラインのアイデンティティに基づいて優先順位のセットを制限しながら、将来のIPベースのスキームは、このような依存を避けるために十分に柔軟であるべきであると認識されています。代わりに、認証されたユーザのID、ユーザーの選択と政策の組み合わせは、要求の処理を決定します。
REQ-13: Multiple simultaneous schemes: Some user agents will need to support multiple different priority schemes, as several will remain in use in networks run by different agencies and operators. (Not all user agents will have the means of authorizing callers using different schemes, and thus may be configured at run-time to only recognize certain namespaces.)
REQ-13：複数の同時スキーム：いくつかの異なる機関や事業者が運営するネットワークで使用中のままになりますように、一部のユーザーエージェントが、複数の異なる優先順位方式をサポートする必要があります。 （すべてではないユーザエージェントは、異なるスキームを使用して、発信者を許可する手段を持つことになり、したがってのみ特定の名前空間を認識するように実行時に構成されてもよいです。）
REQ-14: Discovery: A terminal should be able to discover which, if any, priority namespaces are supported by a network element. Discovery may be explicit, where a user agent requests a list of the supported namespaces or it may be implicit, where it attempts to use a particular namespace and is then told that this namespace is not supported. This does not imply that every element has to support the priority scheme. However, entities should be able discover whether a network element supports it or not.
REQ-14：ディスカバリー：端末があれば、優先順位の名前空間をネットワーク要素によって支持され、発見できなければなりません。ユーザエージェントがサポートされた名前空間のリストを要求したところ発見は、明示的であるか、またはそれは、特定の名前空間を使用しようとすると、この名前空間がサポートされていないことを告げている場合には、暗黙のかもしれません。これは、すべての要素が優先方式をサポートするために持っていることを意味するものではありません。しかし、実体は、ネットワーク要素がそれをサポートしているかどうかを知ることができるはずです。
REQ-15: Testing: It must be possible to test the system outside of emergency conditions, to increase the chances that all elements work during an actual emergency. In particular, critical elements such as indication, authentication, authorization and call routing must be testable. Testing under load is desirable. Thus, it is desirable that the SIP indication is available continuously, not just during emergencies.
REQ-15：テスト：それはすべての要素が実際の緊急時に働く機会を増やすために、緊急状態の外でシステムをテストすることが可能でなければなりません。特に、そのような指示は、認証、許可、およびコールルーティングなどの重要な要素は、検証可能でなければなりません。負荷の下でテストすることが望ましいです。これにより、SIPの指示がないだけ緊急時に、継続的に利用可能であることが望ましいです。
REQ-16: 3PCC: The system has to work with SIP third-party call control.
REQ-16：3PCC：システムは、SIPサードパーティコール制御で動作するように持っています。
REQ-17: Proxy-visible: Proxies may want to use the indication to influence request routing (see Section 7) or impose additional authentication requirements.
REQ-17：プロキシ可視：プロキシは、リクエストルーティングに影響を与える指標を使用する（セクション7参照）または追加の認証要件を課すことができます。
Any resource priority mechanism can be abused to obtain resources and thus deny service to other users. While the indication itself does not have to provide separate authentication, any SIP request carrying such information has more rigorous authentication requirements than regular requests. Below, we describe authentication and authorization aspects, confidentiality and privacy requirements, protection against denial of service attacks and anonymity requirements. Additional discussion can be found in [6].
任意のリソース優先順位メカニズムは、リソースを得るため、他のユーザーへのサービスを拒否するために悪用されることができます。表示自体が独立した認証を提供する必要はありませんが、そのような情報を運ぶ任意のSIPリクエストは、通常の要求よりも厳格認証要件があります。以下に、私たちは、機密性とプライバシー要件、サービス拒否攻撃や匿名性要件の拒否に対する保護、認証と認可の側面を記述する。追加の議論は、[6]に記載されています。
SEC-1: More rigorous: Prioritized access to network and end system resources enumerated in Section 3 imposes particularly stringent requirements on authentication and authorization mechanisms since access to prioritized resources may impact overall system stability and performance, not just result in theft of, say, a single phone call.
SEC-1：より厳密：3章に列挙ネットワークとエンドシステムリソースへの優先アクセスを優先リソースへのアクセスは、たとえば、システム全体の安定性とパフォーマンスに影響を与えるだけの盗難をもたらさない可能性があるため、認証および認可メカニズムに特に厳しい要件を課し、単一の電話。
The authentication and authorization requirements for ETS calls are, in particular, much stronger than for emergency calls (112, 911), where wide access is the design objective, sacrificing caller identification if necessary.
ETSコールの認証と承認の要件が必要な場合は、発信者IDを犠牲にすること、特に、全体のアクセスが設計目標である緊急通報（112、911）、よりもはるかに強いです。
SEC-2: Attack protection: Under certain emergency conditions, the network infrastructure, including its authentication and authorization mechanism, may be under attack. Thus, authentication and authorization must be able to survive such attacks and defend the resources against these attacks.
SEC-2：攻撃の保護：その認証および承認メカニズムを含む特定の緊急事態、ネットワークインフラストラクチャ、下では、攻撃の下にあってもよいです。このように、認証および承認は、このような攻撃を生き残るためには、これらの攻撃から資源を守ることができなければなりません。
Mechanisms to delegate authentication and to authenticate as early as possible are required. In particular, the number of packets and the amount of other resources such as computation or storage that an unauthorized user can consume needs to be minimized.
認証を委任し、できるだけ早期に認証するためのメカニズムが必要とされています。具体的には、パケットの数、不正ユーザが最小化される必要が消費することができ、このような計算や記憶装置などの他のリソースの量。
Unauthorized users must not be able to block CSN resources, as they are likely to be more scarce than packet resources. This implies that authentication and authorization must take place on the IP network side rather than using, say, a CSN circuit to authenticate the caller via a DTMF sequence.
彼らは、パケットのリソースよりも希少である可能性が高いと権限のないユーザーは、CSNのリソースをブロックすることはできません必要があります。これは、認証と認可ではなくDTMF配列を介して発信者を認証するために、たとえば、CSN回路を使用するよりも、IPネットワーク側で行わなければならないことを意味します。
Given the urgency during emergency events, normal statistical fraud detection may be less effective, thus placing a premium on reliable authentication.
緊急事態時の緊急性を考えると、通常の統計的な不正検出は、このように信頼性の高い認証にプレミアムを配置し、あまり効果的です。
SIP nodes should be able to independently verify the authorization of requests to receive prioritized service and not rely on transitive trust within the network.
SIPノードは独立して、優先順位のサービスを受けるために要求の許可を確認し、ネットワーク内で推移的な信頼に依存しないことができるはずです。
SEC-3: Independent of mechanism: Any indication of the resource priority must be independent of the authentication mechanism, since end systems will impose different constraints on the applicable authentication mechanisms. For example, some end systems may only allow user input via a 12-digit keypad, while others may have the ability to acquire biometrics or read smartcards.
SEC-3：機構の独立：エンドシステムが適用可能な認証メカニズムに異なる制約を課すので、リソース優先順位の兆候は、認証メカニズムとは無関係でなければなりません。他のバイオメトリクスを取得またはスマートカードを読み取る能力を有することができる、例えば、いくつかのエンドシステムのみ、12桁のキーパッドを介してユーザ入力を可能にすることができます。
SEC-4: Non-trusted end systems: Since ETS users may use devices that are not their own, systems should support authentication mechanisms that do not require the user to reveal her secret, such as a PIN or password, to the device.
SEC-4：非信頼できるエンドシステム：ETSのユーザーが自分でないデバイスを使用することができますので、システムは、デバイスには、そのようなPINやパスワードなど、彼女の秘密を明らかにするために、ユーザを必要としない認証メカニズムを、サポートする必要があります。
SEC-5: Replay: The authentication mechanisms must be resistant to replay attacks.
SEC-5：リプレイ：認証メカニズムは、リプレイ攻撃に耐性でなければなりません。
SEC-6: Cut-and-paste: The authentication mechanisms must be resistant to cut-and-paste attacks.
SEC-6：カットアンドペースト：認証メカニズムは、攻撃アンドペースト切断に対して耐性でなければなりません。
SEC-7: Bid-down: The authentication mechanisms must be resistant to bid down attacks.
SEC-7：入札ダウン：認証メカニズムは、攻撃をダウン入札に耐性でなければなりません。
SEC-8: Confidentiality: All aspects of ETS are likely to be sensitive and should be protected from unlawful intercept and alteration. In particular, requirements for protecting the confidentiality of communications relationships may be higher than for normal commercial service. For SIP, the To, From,
SEC-8：機密性：ETSのすべての側面が敏感である可能性が高いと違法な傍受や改ざんから保護されなければなりません。具体的には、通信関係の機密性を保護するための要件は、通常の商用サービスのためのより高くてもよいです。 SIPについては、、から、
Organization, Subject, Priority and Via header fields are examples of particularly sensitive information. Callers may be willing to sacrifice confidentiality if the only alternative is abandoning the call attempt.
組織は、件名、優先度とViaヘッダフィールドは、特に機密情報の一例です。唯一の選択肢は、コールの試みを放棄した場合、発信者は、機密性を犠牲にするかもしれません。
Unauthorized users must not be able to discern that a particular request is using a resource priority mechanism, as that may reveal sensitive information about the nature of the request to the attacker. Information not required for request routing should be protected end-to-end from intermediate SIP nodes.
権限のないユーザーは、それが攻撃者に要求の性質に関する機密情報を明らかにすることができるように特定の要求は、リソースの優先度機構を使用していることを識別することがあってはなりません。要求のルーティングのために必要とされない情報は、エンドツーエンドの中間SIPノードから保護されなければなりません。
The act of authentication, e.g., by contacting a particular server, itself may reveal that a user is requesting prioritized service.
認証の動作は、例えば、特定のサーバを接触させることによって、それ自体は、ユーザが優先サービスを要求していることを明らかにしてもよいです。
SIP allows protection of header fields not used for request routing via S/MIME, while hop-by-hop channel confidentiality can be provided by TLS or IPsec.
ホップバイホップチャネルの機密性は、TLSやIPsecによって提供することができるが、SIPは、S / MIMEを介して要求をルーティングするために使用されていないヘッダーフィールドの保護を可能にします。
SEC-9: Anonymity: Some users may wish to remain anonymous to the request destination. For the reasons noted earlier, users have to authenticate themselves towards the network carrying the request. The authentication may be based on capabilities and noms, not necessarily their civil name.
SEC-9：匿名：一部のユーザーには、要求先に匿名を希望することがあります。先に述べた理由から、ユーザーが要求を運ぶネットワークに向けて自分自身を認証する必要があります。認証は、彼らの市民名前必ずしも、機能とNOMSに基づくことができます。
Clearly, they may remain anonymous towards the request destination, using the network-asserted identity and general privacy mechanisms [7,8].
明らかに、彼らはネットワークアサートアイデンティティおよび一般的なプライバシーのメカニズム[7,8]を使用して、依頼先への匿名のままです。
SEC-10: Denial-of-service: ETS systems are likely to be subject to deliberate denial-of-service attacks during certain types of emergencies. DOS attacks may be launched on the network itself as well as its authentication and authorization mechanism.
SEC-10：サービス拒否：ETSシステムは、緊急事態の特定の種類の中に意図的なサービス拒否攻撃の対象になる可能性が高いです。 DOS攻撃は、ネットワーク自体だけでなく、その認証および承認メカニズムに発足することができます。
SEC-11: Minimize resource use by unauthorized users: Systems should minimize the amount of state, computation and network resources that an unauthorized user can command.
SEC-11：権限のないユーザーによるリソース使用を最小化：システムは、不正ユーザーが命令することができる状態、計算およびネットワークリソースの量を最小限に抑える必要があります。
SEC-12: Avoid amplification: The system must not amplify attacks by causing the transmission of more than one packet or SIP request to a network address whose reachability has not been verified.
SEC-12：増幅を避ける：システムは、到達可能性を検証されていないネットワークアドレスに複数のパケットまたはSIPリクエストの送信を引き起こすことによって攻撃を増幅してはなりません。
Section 10 discusses the security issues related to priority indication for SIP in detail and derives requirements for the SIP indicator. As discussed in Section 6, identification of priority service should avoid multiple concurrent mechanisms, to avoid allowing attackers to exploit inconsistent labeling.
セクション10は、詳細にSIPの優先指示に関連するセキュリティ問題について説明し、SIPインジケータの要件を導出します。第6節で議論したように、優先サービスの識別は、攻撃者が一貫性のない標識を利用できるように回避するために、複数の同時のメカニズムを避けるべきです。
Ran Atkinson, Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, Janet Gunn, Kimberly King, Rohan Mahy and James Polk provided helpful comments.
アトキンソン、フレッド・ベイカー、スコット・ブラッドナー、イアン・ブラウン、ケン・カールバーグ、ジャネット・ガン、キンバリー・キング、ローハンマーイとジェームズ・ポークは役に立ちコメントを提供しました。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Lennox, J., Schulzrinne, H. and J. Rosenberg, "Common Gateway Interface for SIP", RFC 3050, January 2001.
[2]レノックス、J.、Schulzrinneと、H.およびJ.ローゼンバーグ、 "SIPのためのCommon Gateway Interface"、RFC 3050、2001年1月。
[3] Lennox J. and H. Schulzrinne, "CPL: A language for user control of internet telephony services", Work in Progress.
[3]レノックスJ.とH. Schulzrinneと、「CPL：インターネット電話サービスのユーザ制御のための言語」が進行中で働いています。
[4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
[4] Zimmerer、E.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.およびM. Zonoun、 "ISUPとQSIGオブジェクトのMIMEメディアタイプ"、RFC 3204 、2001年12月。
[5] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): (SIP-T)", BCP 63, RFC 3372, September 2002.
[5] Vemuri、A.および "電話用のセッション開始プロトコル（SIP-T）：（SIP-T）" J.ピーターソン、BCP 63、RFC 3372、2002年9月。
[6] Brown, I., "A security framework for emergency communications", Work in Progress.
[6]ブラウン、I.、「緊急通信のためのセキュリティフレームワーク」が進行中で働いています。
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[7]ピーターソン、J.、RFC 3323 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"、2002年11月。
[8] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[8]ワトソン、M.は、2002年11月、RFC 3324、 "ネットワークのための短期要件は、アイデンティティをアサート"。
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。