[要約] RFC 3487は、SIP（Session Initiation Protocol）のためのリソース優先度メカニズムの要件を定義しています。このRFCの目的は、SIPセッションの品質とパフォーマンスを向上させるために、リソースの優先度付けと制御を可能にすることです。
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)
セッション開始プロトコル（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.
Copyright（c）The Internet Society（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]を含むリアルタイム通信アプリケーションの要件のみをカバーしています。
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.
リクエストルーティングは、SIPのコアコンポーネントであり、セクション7で説明されています。
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自体のリソースが混雑する可能性があります。これは、MLPPなどの従来のリソース優先順位付けメカニズムの領域であり、Queuingの優先順位または先制に基づいてETS通信に回路が付与されます（ローカル電気通信規制政策と現地管理手続きによって許可されている場合）。ゲートウェイは、代替ルーティング（セクション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.
受信エンドシステムリソース：エンドシステムには、自動コール配布システム（ACDS）またはメディアサーバー、および従来の電話のようなデバイスが含まれる場合があります。ゲートウェイもエンドシステムですが、以前に議論されています。
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.
受信エンドシステムは有限数のセッションのみを管理できるため、優先順位の高い呼び出しが既存の呼び出しを先取りするか、高優先度の呼び出しが待っていることをCalleeに示す必要がある場合があります。（正確なユーザーエージェントの動作は、このドキュメントの範囲を超えており、ポリシーと実装の問題と見なされます。）このような終了サービスは、たとえば緊急調整センターを避けるために必要になる場合があります。ただし、優先順位付けを超えた他のアプローチ、たとえば、地理的起源によってドロップされるランダムリクエストは、優先順位付けされた呼び出しの数が終了容量を超える場合に使用する必要があります。このようなアプローチは、このメモの範囲を超えています。
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プロキシには多くの場合、リクエスト処理能力が大きくなりますが、その能力はアクセスネットワーク帯域幅よりも小さくなる可能性があります。（特にこれは真実です。さまざまなSIP要求は、外部サービス、SIP-CGI [2]、CPL [3]スクリプトなどを呼び出すかどうかに応じて、非常に異なる量のプロキシ計算リソースを消費するためです。したがって、アクセスを制限することでプロキシ過負荷を回避する帯域幅は、プロキシの非効率的な利用につながる可能性があります。）したがって、一部のタイプのプロキシは、過負荷の下で選択した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.
応答は、当然、対応する要求と同じ治療を受ける必要があります。応答はすでにリクエストに安全にマッピングする必要があるため、この要件は大きな負担をもたらさない。プロキシは多くの場合、コール状態を維持していないため、一般的に、優先順位の低いCalleeからのリクエストに優先度を割り当てて、高恵まれた呼び出し元に戻すことはできません。
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-to-CSN（開始時のIP）：リクエストオリジネーターはIPネットワークにあり、CalleeはCSNにあります。明らかに、このモデルは、インスタントメッセージングサービスをサポートするものなどの一般的な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-to-IP（最後にIP）：コールはCSNに発生し、IPネットワークでインターネットテレフォニーゲートウェイを介して終了します。
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-to-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.
CSN-To-IPゲートウェイが、最終目的地がIPネットワーク、CSN、またはSIPフォーキングを介して両方であるかどうかを知ることはほとんどないことを強調する価値があります。
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パケットを懸念なく運ぶため、Common-Carrierネットワークとも呼ばれます。
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透明性のあるネットワークにより、ユーザーはSIPコールを配置して受信できます。ネットワークは、認証の対象となる可能性のあるすべての有効なSIPメッセージのイングレスと出口を可能にします。同様に、RTPメディアストリームを両方向に許可します。ただし、インバウンドまたはアウトバウンド方向のいずれかで、RSVPなどの他のプロトコルをブロックしたり、ゼロ以外のDSCPを許可したりする場合があります。たとえば、SIP/RTPの透明性には多くの程度があります。たとえば、ファイアウォールにSDPコンテンツの検査が必要かどうかに応じて、特定のSIPメッセージボディのエンドツーエンドの暗号化、またはアウトバウンドコールのみが許可されているかどうか。ホテルなどの多くのファイアウォールされた企業ネットワークとセミパブリックアクセスネットワークは、このカテゴリに分類される可能性があります。
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.
別の明確な問題は、GetSが使用する710の市外局番など、特別なアクセス番号へのアクセスを管理上禁止または構成しないSIPネットワークです。このような運用障害は、プロトコル仕様の範囲を超えています。
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リクエストのルーティング、つまり訪問するプロキシとそれが終了するUASは、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では、第1選択キャリアを介して完了できない場合、代替のGetSovabled Interexchange Carrier（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環境で同様の機能を提供するためのいくつかの要件です。セキュリティ要件については、セクション10で説明します。この機能は「SIP表示」と呼び、「ラベル付きリクエスト」などの表示を伝えるリクエストを参照します。
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：1つのスキームまたは国に固有のものではありません。SIP表示は、既存および将来の優先度スキームをサポートする必要があります。たとえば、現在、広く使用されている少なくとも4つの優先度スキームがあります：Q.735、米国防衛電話網（「DSN」または「Autovon」）とNATOによっても実装されています。Telecommunications Systems）より高い優先度と英国政府の電話選好スキーム（GTPS）システムを伴うスキーム。これは、ダイヤルトーンの受信に3つの優先レベルを提供します。
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表示は、強化に気付いていないIPネットワークおよびSIP/RTP透明ネットワークで使用できる必要があります。
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.
両方のCSNがISUPなどの同じシグナル伝達プロトコルまたはプロトコルバージョンを使用していると仮定することはできません。そのため、MIME [4,5]の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分間のセッションに制限されることをqueuingの優先順位を付与する必要があることを指定する代わりに、リクエストは特定の実装にそれらのプロパティを持っている可能性のある特定の名前のポリシーを呼び出します。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：Method-Neutral：選択したSIP表示は、たとえば、たとえば招待者だけでなく、あらゆるSIPメソッドで機能する必要があります。
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システムによって動機付けられています。たとえば、Getsおよび同様のシステムでは、発信者は、限られたセットではなく、コール完了の確率を高める任意の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のFrom HeaderフィールドなどのユーザーIDは、リクエストの優先度レベルを特定するには不十分です。同じアイデンティティは、優先順位のないリクエストと同様に優先順位付けされた要求を発行することができ、優先順位の範囲は発信者の職務機能によって決定されます。優先順位の選択は、各条件の正確なマッピングではなく、類推によって適用される可能性が高い一連の一般的なルールに従って、人間の判断に基づいて行われます。たとえば、特定の状況は、明示的にリストされているものと比較して同様に重大と見なされる場合があります。
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ベースのスキームはそのような信頼を回避するのに十分柔軟であるべきであることが認識されています。代わりに、認証されたユーザーのアイデンティティ、ユーザーの選択、ポリシーの組み合わせにより、リクエストトリートメントが決定されます。
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で列挙されたネットワークおよびエンドのシステムリソースへの優先順位付けアクセスは、優先順位付けされたリソースへのアクセスが全体的なシステムの安定性とパフォーマンスに影響を与える可能性があるため、認証と承認のメカニズムに特に厳しい要件を課します。1回の電話。
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コールの認証と承認の要件は、緊急コール（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ユーザーは独自のデバイスを使用する可能性があるため、システムは、ユーザーがピンやパスワードなどの秘密をデバイスに明らかにする必要のない認証メカニズムをサポートする必要があります。
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, 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.
SEC-8：機密性：ETSのすべての側面は敏感である可能性が高く、違法な傍受と変更から保護されるべきです。特に、通信関係の機密性を保護するための要件は、通常の商業サービスよりも高い場合があります。SIPの場合、to、from、組織、主題、優先度、およびヘッダーフィールドを介して、特に機密情報の例です。唯一の代替案がコールの試みを放棄している場合、発信者は機密性を犠牲にすることをいとわないかもしれません。
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.
SIPを使用すると、S/MIMEを介したリクエストルーティングに使用されないヘッダーフィールドの保護が可能になり、ホップバイホップチャネルの機密性はTLSまたはIPSECによって提供できます。
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：匿名：一部のユーザーは、リクエスト宛先に匿名のままにしたい場合があります。前述の理由により、ユーザーはリクエストを伝えるネットワークに対して自分自身を認証する必要があります。認証は、必ずしも彼らの市民名ではなく、能力とノムに基づいている場合があります。
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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Lennox, J., Schulzrinne, H. and J. Rosenberg, "Common Gateway Interface for SIP", RFC 3050, January 2001.
[2] Lennox、J.、Schulzrinne、H。、およびJ. Rosenberg、「SIPの共通ゲートウェイインターフェイス」、RFC 3050、2001年1月。
[3] Lennox J. and H. Schulzrinne, "CPL: A language for user control of internet telephony services", Work in Progress.
[3] Lennox 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.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、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。およびJ. Peterson、「電話のセッション開始プロトコル（SIP-T）：（ SIP-T）：（SIP-T）、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。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[8] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[8] ワトソン、M。、「ネットワーク主張されたアイデンティティの短期要件」、RFC 3324、2002年11月。
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピューターサイエンスコロンビア大学のヘニングシュルツリン部1214アムステルダムアベニューニューヨーク、ニューヨーク10027 USA
EMail: schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。