Network Working Group                                     T. Taylor, Ed.
Request for Comments: 5069                                        Nortel
Category: Informational                                    H. Tschofenig
                                                  Nokia Siemens Networks
                                                          H. Schulzrinne
                                                     Columbia University
                                                            M. Shanmugam
                                                                 Detecon
                                                            January 2008
        
                 Security Threats and Requirements for
                   Emergency Call Marking and Mapping
        

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Abstract

抽象

This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.

この文書では、それらが緊急事態に関連していることを示すためにシグナリングメッセージのマーキングに関連するセキュリティ上の脅威をレビューし、ユニバーサルリソース識別子(URIの)ポイント(のPSAP)に応答公安にそのポイントへのマッピング位置のプロセスと。このマッピングは、IPネットワークを介して緊急コールをルーティングするプロセスの一部として発生します。

Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls.

識別された脅威に基づいて、この文書は、マッピングプロトコルのため、緊急でマークされたコールの処理のためのセキュリティ要件のセットを確立します。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Marking, Mapping, and the Emergency Call Routing Process . . .  3
     3.1.  Call Marking . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Objectives of Attackers  . . . . . . . . . . . . . . . . . . .  4
   5.  Potential Attacks  . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Attacks Involving the Emergency Identifier . . . . . . . .  5
     5.2.  Attacks Against or Using the Mapping Process . . . . . . .  5
       5.2.1.  Attacks Against the Emergency Response System  . . . .  6
       5.2.2.  Attacks to Prevent a Specific Individual from
               Receiving Aid  . . . . . . . . . . . . . . . . . . . .  7
       5.2.3.  Attacks to Gain Information about an Emergency . . . .  7
   6.  Security Requirements Relating to Emergency Marking and
       Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
        
1. Introduction
1. はじめに

Legacy telephone network users can summon help for emergency services (such as an ambulance, the fire department, and the police) using a well known number (e.g., 911 in North America, 112 in Europe). A key factor in the handling of such calls is the ability of the system to determine caller location and to route the call to the appropriate Public Safety Answering Point (PSAP) based on that location. With the introduction of IP-based telephony and multimedia services, support for emergency calling via the Internet also has to be provided. Two core components of IP-based emergency calling include an emergency service identifier and a mapping protocol. The emergency service identifier indicates that the call signaling establishes an emergency call, while the mapping protocol translates the emergency service identifier and the caller's geographic location into an appropriate PSAP URL.

レガシー電話網ユーザーは、(北米、欧州では112で、例えば、911)は、よく知られた番号を使用して(例えば救急車、消防、警察など)緊急サービスのヘルプを召喚することができます。このような呼の取り扱いの重要な要因は、その位置に基づいて、ポイント(PSAP)に応答適切な公共安全にコールを発信者の位置を決定し、ルーティングするためのシステムの能力です。 IPベースのテレフォニーおよびマルチメディアサービスの導入により、インターネット経由での緊急通話のためのサポートも提供する必要があります。 IPベースの緊急通話の2つのコア・コンポーネントは、緊急サービス識別子とマッピング・プロトコルを含みます。緊急サービス識別子は、マッピングプロトコルは、適切なPSAPのURLへの緊急サービス識別子と発信者の地理的位置を変換しながら、コールシグナリングは、緊急呼を確立することを示しています。

Attacks against the Public Switched Telephone Network (PSTN) have taken place for decades. The Internet is seen as an even more hostile environment. Thus, it is important to understand the types of attacks that might be mounted against the infrastructure providing emergency services and to develop security mechanisms to counter those attacks. While this can be a broad topic, the present document restricts itself to attacks on the mapping of locations to PSAP URIs and attacks based on emergency marking. Verification by the PSAP operator of the truthfulness of a reported incident and various other attacks against the PSAP infrastructure related to the usage of faked location information are outside the scope of the document.

公衆に対する攻撃は、電話網(PSTN)は数十年にわたって行われているスイッチ。インターネットはより厳しい環境として見られています。このように、緊急サービスを提供するインフラストラクチャに対してマウントされるかもしれない攻撃の種類を理解するために、これらの攻撃に対抗するためのセキュリティの仕組みを開発することが重要です。これは、幅広い話題になることができますが、現在のドキュメントには、マーキング、緊急に基づいてPSAPのURIと攻撃への場所のマッピングへの攻撃に自分自身を制限します。報告されたインシデントと偽造位置情報の使用に関連するPSAPのインフラに対して様々な他の攻撃の真実のPSAPオペレータによる検証は、文書の範囲外です。

This document is organized as follows: Section 2 describes basic terminology. Section 3 briefly describes how emergency marking and mapping fit within the process of routing emergency calls. Section 4 describes some motivations of attackers in the context of emergency calling, Section 5 describes and illustrates the attacks that might be used, and Section 6 lists the security-related requirements that must be met if these attacks are to be mitigated.

次のようにこの文書では、構成されています。第2節では、基本的な用語について説明します。第3節では、簡単に緊急コールをルーティングするプロセスの中でどのように緊急マーキングとマッピングフィット感を示しています。第4節では、第5節で説明して使用されるかもしれない攻撃を示しており、第6節のリストこれらの攻撃が軽減される場合に満たされなければならないセキュリティ関連の要件、緊急呼び出しのコンテキストで攻撃者のいくつかの動機を説明しています。

2. Terminology
2.用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the qualification that unless otherwise stated, they apply to the design of the mapping protocol, not its implementation or application.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように、特に明記しない限り、それらはマッピングプロトコルの設計ではなく、その実施またはアプリケーションに適用されること資格と、解釈されます。

The terms "call taker", "mapping service", "emergency caller", "emergency identifier", "mapping", "mapping client", "mapping server", "mapping protocol", and "Public Safety Answering Point (PSAP)" are taken from [RFC5012].

用語「コールテイカー」、「マッピングサービス」、「緊急の発信者」、「緊急識別子」、「マッピング」、「マッピング・クライアント」、「マッピング・サーバ」、「マッピングプロトコル」、および「公安は応答ポイント(PSAP) "[RFC5012]から取得されます。

The term "location information" is taken from RFC 3693 [RFC3693].

用語「位置情報」は、RFC 3693 [RFC3693]から取られます。

The term "emergency caller's device" designates the IP host closest to the emergency caller in the signalling path between the emergency caller and the PSAP. Examples include an IP phone running SIP, H.323, or a proprietary signalling protocol, a PC running a soft client or an analogue terminal adapter, or a residential gateway controlled by a softswitch.

用語「緊急呼び出し側のデバイスは、」緊急時の発信者とPSAPとの間のシグナリングパスの緊急呼び出し側に最も近いIPホストを指定します。例としては、SIP、H.323、または独自のシグナリングプロトコル、ソフトクライアントまたはアナログターミナルアダプタ、またはソフトスイッチによって制御されるレジデンシャルゲートウェイを実行しているPCを実行してIP電話を含みます。

3. Marking, Mapping, and the Emergency Call Routing Process
3.マーキング、マッピング、および緊急コールルーティングプロセス

This memo deals with two topics relating to the routing of emergency calls to their proper destination: call marking and mapping.

呼び出しはマーキングとマッピング:このメモは、二つのトピックは、その適切な宛先に緊急コールのルーティングに関連を扱っています。

3.1. Call Marking
3.1. コールマーキング

Marking of call signalling enables entities along the signalling path to recognize that a particular signalling message is associated with an emergency call. Signalling containing the emergency identifier may be given priority treatment, special processing, and/or special routing.

コールシグナリングのマーキングは、シグナリング経路に沿ったエンティティが特定のシグナリングメッセージが緊急呼に関連付けられていることを認識することが可能となります。緊急識別子を含むシグナリングが優先処理、特殊処理、及び/又は特別なルーティングを与えることができます。

3.2. Mapping
3.2. マッピング

An important goal of emergency call routing is to ensure that any emergency call is routed to a PSAP. Preferably, the call is routed to the PSAP responsible for the caller's location, since misrouting consumes valuable time while the call taker locates and forwards the call to the right PSAP. As described in [RFC5012], mapping is part of the process of achieving this preferable outcome.

緊急コールルーティングの重要な目標は、すべての緊急コールがPSAPにルーティングされることを保証することです。コール受け手が見つけて右PSAPにコールを転送しながらmisroutingは貴重な時間を消費するので好ましく、コールは、発信者の場所を担当するPSAPにルーティングされます。 [RFC5012]に記載されているように、マッピングは、この好ましい結果を達成するためのプロセスの一部です。

In brief, mapping involves a mapping client, a mapping server, and the protocol that passes between them. The protocol allows the client to pass location information to the mapping server and to receive back a URI, which can be used to direct call signalling to a PSAP.

簡単に言えば、マッピングは、マッピング・クライアント、マッピングサーバ、およびそれらの間を通過するプロトコルを必要とします。プロトコルは、クライアントが、マッピング・サーバに位置情報を渡すと、PSAPへのコールシグナリングを指示するために使用することができるURIを、バック受け取ることを可能にします。

4. Objectives of Attackers
攻撃者の目的4.

Attackers may direct their efforts either against a portion of the emergency response system or against an individual. Attacks against the emergency response system have three possible objectives:

攻撃者は、緊急応答システムの部分に対して、または個々に対するいずれかの努力を指示することができます。緊急対応システムに対する攻撃は、次の3つの目標を持っています:

o to deny system services to all users in a given area. The motivation may range from thoughtless vandalism, to wide-scale criminality, to terrorism. One interesting variant on this motivation is the case where a victim of a large emergency hopes to gain faster service by blocking others' competing calls for help.

指定したエリア内のすべてのユーザにシステムサービスを拒否するO。動機は軽率破壊行為から、大規模な犯罪に、テロの範囲であってもよいです。この動機の一つの興味深い変種は、大規模な緊急事態の被害者が助けのために他人の競合の呼び出しをブロックすることにより、迅速なサービスを得ることを期待しているケースです。

o to gain fraudulent use of services, by using an emergency identifier to bypass normal authentication, authorization, and accounting procedures.

oは通常の認証、許可、アカウンティングの手順をバイパスするために緊急の識別子を使用することによって、サービスの不正使用を得るために。

o to divert emergency calls to non-emergency sites. This is a form of a denial-of-service attack similar to the first item, but quite likely more confusing for the caller himself or herself since the caller expects to talk to a PSAP operator but instead gets connected to someone else.

非緊急サイトへの緊急コールをそらすために、O。呼び出し側がPSAPのオペレーターに話をする予定はなく、他の誰かに接続されますので、これは最初の項目に類似のサービス拒否攻撃の形ですが、非常に可能性がさらに混乱、発信者自身のために。

Attacks against an individual fall into two classes:

二つのクラスに個々の秋に対する攻撃:

o attacks to prevent an individual from receiving aid.

援助を受けてから個々のを防ぐために、O攻撃。

o attacks to gain information about an emergency that can be applied either against an individual involved in that emergency or to the profit of the attacker.

Oの攻撃は、緊急時に含まれる個々のに対して、または攻撃者の利益のいずれかに適用することができ、緊急の情報を得るために。

5. Potential Attacks
5.潜在的な攻撃
5.1. Attacks Involving the Emergency Identifier
5.1. 緊急識別子を伴う攻撃

The main possibility of attack involves use of the emergency identifier to bypass the normal procedures in order to achieve fraudulent use of services. An attack of this sort is possible only if the following conditions are true:

攻撃の主な可能性は、サービスの不正使用を達成するために、通常の手順をバイパスする緊急識別子の使用を含みます。この種の攻撃は、以下の条件に該当する場合にのみ可能です。

a. The attacker is the emergency caller.

A。攻撃者は、緊急時の呼び出し元です。

b. The call routing system assumes that the emergency caller's device signals the correct PSAP URI for the caller's location.

B。コールルーティングシステムは、緊急発呼者の装置が発信者の位置の正しいPSAP URIを通知することを想定しています。

c. The call enters the domain of a service provider, which accepts it without applying normal procedures for authentication and authorization because the signalling carries the emergency identifier.

C。コールは、シグナリングが緊急識別子を運ぶための認証および承認のための通常の手順を適用せず、それを受け入れるサービスプロバイダのドメインを入力します。

d. The service provider routes the call according to the called address (e.g., SIP Request-URI), without verifying that this is the address of a PSAP (noting that a URI by itself does not indicate the nature of the entity it is pointing to).

D。サービスプロバイダーのルートと呼ばれるアドレス(例えば、SIPリクエスト-URI)によると、コールが、これはPSAPのアドレスであることを確認せず(それ自体がURIは、それが指している実体の性質を示すものではありませんことに注意) 。

If these conditions are satisfied, the attacker can bypass normal service provider authorization procedures for arbitrary destinations, simply by reprogramming the emergency caller's device to add the emergency identifier to non-emergency call signalling. In this case, the call signalling most likely will not include any location information, or there could be location information, but it is false.

これらの条件が満たされた場合、攻撃者が任意の宛先に対して、単に非緊急コールシグナリングへの緊急識別子を追加するために、緊急呼び出し側のデバイスを再プログラミングすることにより、通常のサービスプロバイダの認証手続きをバイパスすることができます。この場合、最も可能性の高いコールシグナリングは、任意の位置情報が含まれていないか、または位置情報があるかもしれませんが、それは偽です。

An attacker wishing to disrupt the emergency call routing system may use a similar technique to target components of that system for a denial-of-service attack. The attacker will find this attractive to reach components that handle emergency calls only. Flooding attacks are the most likely application of the technique, but it may also be used to identify target components for other attacks by analyzing the content of responses to the original signalling messages.

緊急コールルーティングシステムを破壊したい攻撃者がサービス拒否攻撃のために、そのシステムの構成部品を対象とする同様の技術を使用することができます。攻撃者は、緊急コールのみを処理するコンポーネントに到達するには、この魅力的でしょう。フラッディング攻撃は技術の最も可能性の高いアプリケーションであり、また、元のシグナリングメッセージに対する応答の内容を解析することにより、他の攻撃の標的成分を同定するために使用されてもよいです。

5.2. Attacks Against or Using the Mapping Process
5.2. 攻撃またはマッピングプロセスを使用して

This section describes classes of attacks involving the mapping process that could be used to achieve the attacker goals described in Section 4.

このセクションでは、第4章で説明した攻撃者が目標を達成するために使用できるマッピング処理を伴う攻撃のクラスについて説明します。

5.2.1. Attacks Against the Emergency Response System
5.2.1. 緊急対応システムへの攻撃

This section considers attacks intended to reduce the effectiveness of the emergency response system for all callers in a given area. If the mapping operation is disabled, then the emergency caller's device might not have the correct PSAP URI. As a consequence, the probability that emergency calls will be routed to the wrong PSAP increases. In the worst case, the emergency caller's device might not be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a double consequence: emergency response to the affected calls is delayed, and PSAP call taker resources outside the immediate area of the emergency are consumed due to the extra effort required to redirect the calls. Alternatively, attacks that cause the client to receive a URI that does not lead to a PSAP have the immediate effect of causing emergency calls to fail.

このセクションでは、与えられた領域内のすべての発信者に対して緊急対応システムの有効性を減少させることを意図した攻撃と見なします。マッピング操作が無効になっている場合には、緊急呼び出し側のデバイスが正しいPSAP URIを持っていない可能性があります。その結果、緊急コールが間違ったPSAP増加にルーティングされる確率として。最悪の場合には、緊急呼び出し側のデバイスは、すべてのPSAP URIを取得することができない場合があります。影響を受けたコールへの緊急対応が遅れている、と緊急時の即時エリア外PSAPコールテイカーリソースが呼び出しをリダイレクトするために必要な余分な努力のために消費されています。間違ったPSAPにルーティングすることは二重の結果を有します。また、PSAPにつながらないクライアントは、URIを受信する原因となる攻撃は、緊急呼び出しが失敗する原因の即時効果を持ちます。

Three basic attacks on the mapping process can be identified: denial of service, impersonation of the mapping server, or corruption of the mapping database. Denial of service can be achieved in several ways:

マッピングプロセスには3回の基本的な攻撃を識別することができます:サービス拒否、マッピングサーバのなりすまし、またはマッピングデータベースの破損を。サービスの拒否は、いくつかの方法で達成することができます。

o by a flooding attack on the mapping server;

マッピングサーバ上のフラッディング攻撃により、O。

o by taking control of the mapping server and either preventing it from responding or causing it to send incorrect responses; or

マッピングサーバの制御を取得し、いずれかの応答または不正な応答を送信するためにそれを引き起こしてからそれを防止することによって、O。または

o by taking control of any intermediary node (for example, a router) through which the mapping queries and responses pass, and then using that control to block them. An adversary may also attempt to modify the mapping protocol signalling messages. Additionally, the adversary may be able to replay past communication exchanges to fool an emergency caller by returning incorrect results.

Oマッピングクエリ及び応答が通過する(例えば、ルータ)は、任意の中間ノードの制御を取るし、それらをブロックするためにその制御を使用することによって。敵はまた、シグナリングメッセージをマッピングプロトコルを変更しようとすることができます。また、敵は誤った結果を返すことによって、緊急発信者をだますために過去の通信のやり取りを再生することができるかもしれません。

In an impersonation attack, the attacker induces the mapping client to direct its queries to a host under the attacker's control rather than the real mapping server, or the attacker suppresses the response from the real mapping server and sends a spoofed response.

なりすまし攻撃では、攻撃者は、攻撃者の制御下にあるホストではなく、実際のマッピングサーバへのクエリを指示するマッピング・クライアントを誘導する、または攻撃者は、実際のマッピングサーバからの応答を抑制し、偽装された応答を送信します。

The former type of impersonation attack itself is an issue of mapping server discovery rather than the mapping protocol directly. However, the mapping protocol may allow impersonation to be detected, thereby preventing acceptance of responses from an impersonating entity and possibly triggering a more secure discovery procedure.

なりすまし攻撃自体の前者のタイプは、マッピングサーバ発見の問題ではなく、直接マッピングプロトコルです。しかしながら、マッピング・プロトコルは、それによって偽装エンティティからの応答の受け入れを防止し、おそらくより安全な発見手順をトリガする、なりすましを検出することを可能にすることができます。

Corruption of the mapping database cannot be mitigated directly by mapping protocol design. Once corruption has been detected, the mapping protocol may have a role to play in determining which records have been corrupted.

マッピングデータベースの破損は、マッピングプロトコル設計によって直接軽減することができません。破損が検出されると、マッピングプロトコルが破損されたレコードを決定する上で果たすべき役割を有することができます。

Beyond these attacks on the mapping operation itself, it is possible to use mapping to attack other entities. One possibility is that mapping clients are misled into sending mapping queries to the target of the attack instead of the mapping server. Prevention of such an attack is an operational issue rather than one of protocol design. Another possible attack is where the mapping server is tricked into sending responses to the target of the attack through spoofing of the source address in the query.

マッピング操作自体にこれらの攻撃以外にも、他のエンティティを攻撃するためにマッピングを使用することが可能です。一つの可能​​性は、マッピングクライアントが代わりにマッピングサーバの攻撃のターゲットにマッピングクエリを送信するに誤解されていることです。このような攻撃の防止は運用の問題ではなく、プロトコル設計の一つです。マッピングサーバがクエリのソースアドレスのスプーフィングによる攻撃のターゲットに応答を送信するようにだまされる場合、別の攻撃の可能性があります。

5.2.2. Attacks to Prevent a Specific Individual from Receiving Aid
5.2.2. 援助を受けてから、特定の個人を防止するための攻撃

If an attacker wishes to deny emergency service to a specific individual, the mass attacks described in Section 5.2.1 will obviously work provided that the target individual is within the affected population. Except for the flooding attack on the mapping server, the attacker can in theory limit these attacks to the target, but this requires extra effort that the attacker is unlikely to expend. If the attacker is using a mass attack but does not wish to have too broad an effect, it is more likely to attack for a carefully limited period of time.

攻撃者が特定の個人に緊急サービスを拒否したい場合は、5.2.1項で説明するマス攻撃は明らかにターゲット個人が影響を受けた集団内であることを提供していきます。マッピングサーバ上のフラッディング攻撃を除いて、攻撃者は、理論的にターゲットに、これらの攻撃を制限することができますが、これは、攻撃者が費やすことはほとんどありませんという余分な労力を必要とします。攻撃者が大量の攻撃を使用しているが、あまりにも幅広い効果を持ってしたくない場合は、時間の慎重期間限定で攻撃する可能性が高いです。

If the attacker wants to be selective, however, it may make more sense to attack the mapping client rather than the mapping server. This is particularly so if the mapping client is the emergency caller's device. The choices available to the attacker are similar to those for denial of service on the server side:

攻撃者は、選択的になりたい場合は、しかし、それはマッピング・クライアントではなく、マッピングサーバを攻撃するより多くの意味を行うことができます。マッピング・クライアントは、緊急呼び出し側のデバイスである場合、これは特にそうです。攻撃者が利用可能な選択肢は、サーバー側でのサービス拒否のためのものと同様です。

o a flooding attack on the mapping client;

マッピング・クライアント上でフラッディング攻撃O;

o taking control of any intermediary node (for example, a router) through which the mapping queries and responses pass, and then using that control to block or modify them.

マッピングクエリ及び応答が通過する(例えば、ルータ)は、任意の中間ノードの制御を取るし、それらを遮断または変更するためにそのコントロールを使用して、O。

Taking control of the mapping client is also a logical possibility, but raises no issues for the mapping protocol.

マッピング・クライアントの制御を取ることも論理的な可能性であるが、マッピングプロトコルのための問題を提起しません。

5.2.3. Attacks to Gain Information about an Emergency
5.2.3. 緊急時の情報を得るために攻撃

This section discusses attacks used to gain information about an emergency. The attacker may be seeking the location of the caller (e.g., to effect a criminal attack). Alternatively, the attacker may be seeking information that could be used to link an individual (the caller or someone else involved in the emergency) with embarrassing information related to the emergency (e.g., "Who did the police take away just now?"). Finally, the attacker could be seeking to profit from the emergency, perhaps by offering his or her services (e.g., a news reporter, or a lawyer aggressively seeking new business).

このセクションでは、緊急時の情報を得るために使用攻撃について説明します。攻撃者は、発信者(例えば、犯罪者攻撃を行うために)の位置を求めることができます。また、攻撃者は、緊急事態に関連恥ずかしい情報を(発信者または他の誰かが緊急に関与)個人をリンクするために使用できる情報を求めていること(例えば、「警察は今奪うでした誰?」)。最後に、攻撃者は、おそらく彼または彼女のサービス(例えば、ニュースレポーター、または積極的に新規事業を模索弁護士)を提供することで、緊急事態から利益を追求することができます。

The primary information that interceptions of mapping requests and responses will reveal are a location, a URI identifying a PSAP, the emergency service identifier, and the addresses of the mapping client and server. The location information can be directly useful to an attacker if the attacker has high assurance that the observed query is related to an emergency involving the target. The type of emergency (fire, police, or ambulance) might also be revealed by the emergency service identifier in the mapping query. The other pieces of information may provide the basis for further attacks on emergency call routing, but because of the time factor, are unlikely to be applicable to the routing of the current call. However, if the mapping client is the emergency caller's device, the attacker may gain information that allows for interference with the call after it has been set up or for interception of the media stream between the caller and the PSAP.

マッピング要求と応答の迎撃を明らかにする主な情報はPSAP、緊急サービス識別子、およびマッピング・クライアントとサーバのアドレスを特定する場所、URIです。攻撃者が観察クエリがターゲットに関わる緊急事態に関連していることを高く保証を持っている場合は、位置情報が攻撃者に直接役立つことがあります。緊急事態(火災、警察、または救急車)のタイプは、マッピングクエリ内の緊急サービス識別子によって明らかにされる可能性があります。その他の情報は、緊急コールルーティングのさらなる攻撃のための基礎を提供するが、時間の要因のため、現在のコールのルーティングに適用できそうにないことがあります。マッピング・クライアントは、緊急呼び出し側のデバイスである場合には、攻撃者はそれを設定したり、発信者とPSAP間のメディアストリームの傍受のためにされた後のコールとの干渉を可能にした情報を得てもよいです。

6. Security Requirements Relating to Emergency Marking and Mapping
緊急マーキングとマッピングに関連6.セキュリティ要件

This section describes the security requirements that must be fulfilled to prevent or reduce the effectiveness of the attacks described in Section 5. The requirements are presented in the same order as the attacks.

このセクションでは、要件は攻撃と同じ順序で提示されている第5節で説明された攻撃の有効性を防止または軽減するために満たされなければならないセキュリティ要件を記述します。

From Section 5.1:

セクション5.1から:

Attack A1: fraudulent calls.

攻撃A1:詐欺のコール。

Requirement R1: For calls that meet conditions a) to c) of Section 5.1, the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP.

要件R1は:セクション5.1のa)からcへの条件)を満たすコールの場合、サービスプロバイダのコールルーティングエンティティは、宛先アドレス(例えば、SIPリクエスト-URI)コールシグナリングに提示は、PSAPのものであることを確かめなければなりません。

Attack A2: Use of emergency identifier to probe in order to identify emergency call routing entities for attack by other means.

A2を攻撃:緊急識別子を使用すると、他の手段で攻撃の実体をルーティング緊急通話を識別するためにプローブします。

Requirement: None identified, beyond the ordinary operational requirement to defend emergency call routing entities by means such as firewalls and, where possible, authentication and authorization.

要件:なしファイアウォールや、可能性、認証および承認などの手段によって、エンティティをルーティング緊急通話を守るために通常の運用要件を超えて、特定されていません。

From Section 5.2.1:

セクション5.2.1から:

Attack A3: Flooding attack on the mapping client, mapping server, or a third entity.

攻撃A3:マッピング・クライアント上のフラッディング攻撃、マッピングサーバ、あるいは第3のエンティティ。

Requirement R2: The mapping protocol MUST NOT create new opportunities for flooding attacks, including amplification attacks.

要件R2:マッピングプロトコルは、増幅攻撃を含むフラッディング攻撃のための新しい機会を作成してはいけません。

Attack A4: Insertion of interfering messages.

攻撃A4:メッセージを妨害するの挿入。

Requirement R3: The protocol MUST permit the mapping client to verify that the response it receives is responding to the query it sent out.

要件R3:プロトコルは、それが受け取る応答は、それが送り出されたクエリに応答していることを確認するために、マッピング・クライアントを許可する必要があります。

Attack A5: Man-in-the-middle modification of messages.

攻撃A5:メッセージののman-in-the-middle修正。

Requirement R4: The mapping protocol MUST provide integrity protection of requests and responses.

要件R4:マッピングプロトコルは、要求と応答の完全性保護を提供しなければなりません。

Requirement R5: The mapping protocol or the system within which the protocol is implemented MUST permit the mapping client to authenticate the source of mapping responses.

要件R5:マッピングプロトコルまたはプロトコルが実装されている内のシステムは、マッピング応答のソースを認証するためにマッピング・クライアントを許可する必要があります。

Attack A6: Impersonation of the mapping server.

攻撃A6:マッピングサーバの偽装。

Requirement R6: The security considerations for any discussion of mapping server discovery MUST address measures to prevent impersonation of the mapping server.

要件R6:マッピングサーバ発見のいずれかの議論のためのセキュリティの考慮事項は、マッピングサーバのなりすましを防止するための措置に対処しなければなりません。

Requirement R5 also follows from this attack.

要件R5はまた、この攻撃から続きます。

Attack A7: Corruption of the mapping database.

攻撃A7:マッピングデータベースの破損。

Requirement R7: The security considerations for the mapping protocol MUST address measures to prevent database corruption by an attacker.

要件R7:マッピングプロトコルのためのセキュリティの考慮事項は、攻撃者によってデータベースの破損を防止するための措置に対処しなければなりません。

Requirement R8: The protocol SHOULD include information in the response that allows subsequent correlation of that response with internal logs that may be kept on the mapping server, to allow debugging of mis-directed calls.

要件R8:プロトコルは、誤った方向へのコールのデバッグを可能にするために、マッピング・サーバ上に保持することができる内部ログとその応答のその後の相関を可能に応じて情報を含めるべきです。

From Section 5.2.2: No new requirements.

5.2.2から:いいえ新しい要件。

From Section 5.2.3:

5.2.3項から:

Attack A8: Snooping of location and other information.

攻撃A8:場所およびその他の情報のスヌーピング。

Requirement R9: The protocol and the system within which it is implemented MUST maintain confidentiality of the request and response.

要求R9:それが実施される内プロトコル及びシステムは、要求と応答の機密性を維持しなければなりません。

7. Security Considerations
7.セキュリティの考慮事項

This document addresses security threats and security requirements. Therefore, security is considered throughout this document.

この文書では、セキュリティ上の脅威とセキュリティ要件に対応しています。そのため、セキュリティはこの文書を通して考えられています。

8. Acknowledgements
8.謝辞

The writing of this document has been a task made difficult by the temptation to consider the security concerns of the entire personal emergency calling system, not just the specific pieces of work within the scope of the ECRIT Working Group. Hannes Tschofenig performed the initial security analysis for ECRIT, but it has been shaped since then by the comments and judgement of the ECRIT WG at large. At an earlier stage in the evolution of this document, Stephen Kent of the Security Directorate was asked to review it and provided extensive comments, which led to a complete rewriting of it. Brian Rosen, Roger Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran Aquil, and Ron Watro have also provided detailed reviews of this document at various stages. The authors thank them.

このドキュメントの執筆は、タスクがECRITワーキンググループの範囲内で全体の個人的な緊急コールシステムのセキュリティ上の問題、仕事だけではなく特定の部分を検討する誘惑により困難になってきました。ハンネスTschofenigはECRITのために初期のセキュリティ分析を行ったが、それは大でECRIT WGのコメントと判断で、それ以来整形されました。このドキュメントの進化の早い段階では、セキュリティ総局のスティーブン・ケントは、それを確認するように求め、それを完全に書き換えにつながった大規模なコメントを、提供されました。ブライアン・ローゼン、ロジャー・マーシャル、アンドリュー・ニュートン、そして最近、スペンサードーキンスカムランAquil、そしてロンWatroもさまざまな段階で、このドキュメントの詳細なレビューを提供してきました。著者は、彼らに感謝します。

We would like to thank Donald Eastlake for his review on behalf of the Security Area Directorate and Christian Vogt for his review as part of the General Area Review Team.

私たちは、一般的なエリアレビューチームの一員として彼のレビューのためのセキュリティエリア総局とキリスト教フォークトの代わりに彼のレビューのためにドナルドイーストレイクに感謝したいと思います。

Finally, we would like to thank Jari Arkko, Jon Peterson, and Russ Housley for their IETF Last Call comments.

最後に、我々は彼らのIETFラストコールのコメントをヤリArkko、ジョンピーターソン、とラスHousleyに感謝したいと思います。

9. References
9.参考文献
9.1. Normative References
9.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

9.2. Informative References
9.2. 参考文献

[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。

[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.

[RFC5012] Schulzrinneと、H.とR.マーシャル、エド。、 "インターネット技術との緊急コンテキスト解決のための要件"、RFC 5012、2008年1月。

Authors' Addresses

著者のアドレス

Tom Taylor (editor) Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada

トム・テイラー(エディタ)ノーテル1852ロレーヌアヴェオタワ、オンタリオ州K1H 6Z8カナダ

EMail: tom.taylor@rogers.com

メールアドレス:tom.taylor@rogers.com

Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany

ハンネスTschofenigノキアシーメンスネットワークスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ

EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com

電子メール:Hannes.Tschofenig@nsn.com URI:http://www.tschofenig.com

Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US

コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部

Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu

電話:+1 212 939 7004 Eメール:hgs+ecrit@cs.columbia.edu URI:http://www.cs.columbia.edu

Murugaraj Shanmugam Detecon International GmbH Oberkasseler str 2 Bonn, NRW 53227 Germany

Murugaraj Shanmugam Detecon国際GmbH社Oberkasseler STR 2ボン、NRW 53227ドイツ

EMail: murugaraj.shanmugam@detecon.com

メールアドレス:murugaraj.shanmugam@detecon.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(C)IETFトラスト(2008)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。