[要約] RFC 7406は、認証されていないおよび許可されていないデバイスに対処するための緊急サービスアーキテクチャの拡張に関するものです。このRFCの目的は、緊急サービスへのアクセスを制御し、セキュリティを向上させることです。
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 7406 Columbia University
Category: Informational S. McCann
ISSN: 2070-1721 BlackBerry Ltd
G. Bajko
MediaTek
H. Tschofenig
D. Kroeselberg Siemens Corporate Technology December 2014
D.クローゼルベルクシーメンスコーポレートテクノロジー2014年12月
Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices
認証されていないデバイスを処理するための緊急サービスアーキテクチャの拡張
Abstract
概要
This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.
このドキュメントでは、問題の説明を提供し、用語を紹介し、緊急の発信者が認証されていない、識別可能なサービスプロバイダーがない、またはアクセスへの支払いに必要なクレジットが残っていない場合に対処するための基本IETF緊急サービスアーキテクチャの拡張について説明しますネットワーク。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7406.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7406で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use-Case Categories . . . . . . . . . . . . . . . . . . . . . 5
4. ZBP Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. NASP Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.1. End-Host Profile . . . . . . . . . . . . . . . . . . . . 15
5.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 15
5.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . 15
5.1.3. Location Determination and Location Configuration . . 15
5.1.4. Emergency Call Identification . . . . . . . . . . . . 15
5.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . 15
5.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . 16
5.2.2. Location Determination and Location Configuration . . 16
5.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . 16
5.3.1. Emergency Call Routing . . . . . . . . . . . . . . . 16
5.3.2. Emergency Call Identification . . . . . . . . . . . . 16
5.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . 17
6. Lower-Layer Considerations for NAA Case . . . . . . . . . . . 17
6.1. Link-Layer Emergency Indication . . . . . . . . . . . . . 18
6.2. Securing Network Attachment in NAA Cases . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
Summoning police, the fire department, or an ambulance in emergencies is one of the fundamental and most-valued functions of the telephone. As telephony functionality moves from circuit-switched telephony to Internet telephony, its users rightfully expect that this core functionality will continue to work at least as well as it has for the older technology. New devices and services are being made available that could be used to make a request for help; those devices are not traditional telephones, and users are increasingly expecting them to be able to place emergency calls.
警察、消防署、または緊急時の救急車を呼び出すことは、電話の基本的で最も重要な機能の1つです。テレフォニー機能が回線交換テレフォニーからインターネットテレフォニーに移行するにつれ、ユーザーはこのコア機能が少なくとも古いテクノロジと同様に引き続き機能することを期待しています。ヘルプのリクエストに使用できる新しいデバイスとサービスが利用可能になっています。これらのデバイスは従来の電話ではなく、ユーザーは緊急電話をかけることができることをますます期待しています。
Roughly speaking, the IETF emergency services architecture (see [RFC6881] and [RFC6443]) divides responsibility for handling emergency calls among the access network (Internet Access Provider (IAP) or ISP); the application service provider (ASP), which may be a VoIP service provider (VSP); and the provider of emergency signaling services, the emergency service network (ESN). The access network may provide location information to end systems but does not have to provide any ASP signaling functionality. The emergency caller can reach the ESN either directly or through the ASP's outbound proxy. Any of the three parties can provide the mapping from location to the Public Safety Answering Point (PSAP) URI by offering Location-to-Service Translation (LoST) [RFC5222] services.
大まかに言えば、IETF緊急サービスアーキテクチャ（[RFC6881]と[RFC6443]を参照）は、緊急通話の処理の責任をアクセスネットワーク（インターネットアクセスプロバイダー（IAP）またはISP）に分割します。アプリケーションサービスプロバイダー（ASP）。VoIPサービスプロバイダー（VSP）の場合もあります。緊急信号サービスのプロバイダーである緊急サービスネットワーク（ESN）。アクセスネットワークは、エンドシステムに位置情報を提供できますが、ASPシグナリング機能を提供する必要はありません。緊急の発信者は、ESNに直接またはASPの発信プロキシを介して到達できます。 3者のいずれも、ロケーションからサービスへの変換（LoST）[RFC5222]サービスを提供することにより、ロケーションからPublic Safety Answering Point（PSAP）URIへのマッピングを提供できます。
In general, a set of automated configuration mechanisms allows a device to function in a variety of architectures, without the user being aware of the details on who provides location, mapping services, or call-routing services. However, if emergency calling is to be supported when the calling device lacks access network authorization or does not have an ASP, one or more of the providers may need to provide additional services and functions.
一般に、一連の自動化された構成メカニズムにより、ユーザーは場所、マッピングサービス、またはコールルーティングサービスを提供するユーザーの詳細を意識することなく、さまざまなアーキテクチャでデバイスを機能させることができます。ただし、発信側デバイスにアクセスネットワーク認証がない場合やASPがない場合に緊急コールをサポートする場合は、1つ以上のプロバイダーが追加のサービスと機能を提供する必要がある場合があります。
In all cases, the end device has to be able to perform a LoST lookup and otherwise conduct the emergency call in the same manner as when the three exceptional conditions discussed below do not apply.
すべての場合において、エンドデバイスはLoSTルックアップを実行できる必要があり、それ以外の場合は、以下で説明する3つの例外的な条件が適用されない場合と同じ方法で緊急コールを実行できます。
We distinguish among three conditions:
3つの条件を区別します。
No Access Authentication (NAA): In the NAA case, the emergency caller does not posses valid credentials for the access network. This includes the case where the access network allows pay-per-use, as is common for wireless hotspots, but there is insufficient time to enter credit card details and other registration information required for access. It also covers all cases where either no credentials are available at all or the available credentials do not work for the given IAP/ISP. As a result, the NAA case basically combines the No ASP (NASP) and zero-balance ASP (ZBP) cases below, but at the IAP/ISP level. Support for emergency call handling in the NAA case is subject to the local policy of the ISP. Such policy may vary substantially between ISPs and typically depends on external factors that are not under the ISP control.
アクセス認証なし（NAA）：NAAの場合、緊急発信者はアクセスネットワークの有効な資格情報を所有していません。これには、ワイヤレスホットスポットのように、アクセスネットワークで従量課金が許可されている場合も含まれますが、クレジットカードの詳細やアクセスに必要なその他の登録情報を入力するのに十分な時間がありません。また、資格情報がまったく利用できない場合や、利用可能な資格情報が特定のIAP / ISPで機能しない場合のすべてのケースについても説明します。その結果、NAAケースは基本的に、以下のASPなし（NASP）とゼロバランスASP（ZBP）のケースを組み合わせたものですが、IAP / ISPレベルです。 NAAケースでの緊急コール処理のサポートは、ISPのローカルポリシーに従います。このようなポリシーは、ISP間で大幅に異なる場合があり、通常、ISPの管理下にない外部要因に依存します。
No ASP (NASP): The caller does not have an ASP at the time of the call. This can occur in case the caller either does not possess any valid subscription for a reachable ASP or does possess a valid subscription but none of the ASPs are reachable through the ISP.
ASPなし（NASP）：発信者は、通話時にASPを持っていません。これは、呼び出し元が到達可能なASPの有効なサブスクリプションを所有していないか、有効なサブスクリプションを所有しているが、ISPを介して到達できるASPがない場合に発生します。
Note: The interoperability need is increased with this scenario since the client software used by the emergency caller must be compatible with the protocols and extensions deployed by the ESN.
注：緊急の発信者が使用するクライアントソフトウェアは、ESNによって展開されたプロトコルおよび拡張機能と互換性がある必要があるため、このシナリオでは相互運用性の必要性が高まります。
Zero-balance ASP (ZBP): In the case of a zero-balance ASP, the ASP can authenticate the caller, but the caller is not authorized to use ASP services, e.g., because the contract has expired or the prepaid account for the customer has been depleted.
ゼロバランスASP（ZBP）：ゼロバランスASPの場合、ASPは呼び出し元を認証できますが、たとえば、契約の有効期限が切れているか、顧客の前払いアカウントがあるため、呼び出し元はASPサービスの使用を許可されていません枯渇しています。
These three cases are not mutually exclusive. A caller in need of help may, for example, be both in an NAA and NASP situation, as explained in more detail in Figure 1. Depending on local policy and regulations, it may not be possible to place emergency calls in the NAA case. Unless local regulations require user identification, it should always be possible to place calls in the NASP case, with minimal impact on the ISP. Unless the ESN requires that all calls traverse a known set of Voice Service Providers (VSPs), it is technically possible to let a caller place an emergency call in the ZBP case. We discuss each case in more detail in Section 3.
これら3つのケースは相互に排他的ではありません。図1で詳細に説明されているように、助けを必要とする発信者は、たとえばNAAとNASPの両方の状況にある可能性があります。地域のポリシーや規制によっては、NAAのケースで緊急通話を発信できない場合があります。地域の規制でユーザーの識別が要求されていない限り、ISPへの影響を最小限に抑えながら、NASPケースに電話をかけることが常に可能でなければなりません。 ESNがすべての通話が既知の音声サービスプロバイダー（VSP）のセットを通過することを要求しない限り、技術的には発信者にZBPケースで緊急通話を発信させることができます。セクション3で各ケースについて詳しく説明します。
Some of the functionality provided in this document is already available in the Public Switched Telephone Network (PSTN). Consequently, there is real-world experience available and not all of it is positive. For example, the functionality of calls without Subscriber Identity Modules (SIMs) in today's cellular system has lead to a fair amount of hoax or test calls in certain countries.
このドキュメントで提供されている機能の一部は、公衆交換電話網（PSTN）で既に利用可能です。その結果、利用可能な現実の経験があり、それのすべてが肯定的ではありません。たとえば、今日のセルラーシステムでのサブスクライバーアイデンティティモジュール（SIM）を使用しない通話の機能により、特定の国ではかなりの量のいたずら電話やテスト通話が発生しています。
This causes overload situations at PSAPs, which is considered harmful to the overall availability and reliability of emergency services.
これにより、PSAPで過負荷状態が発生します。これは、緊急サービスの全体的な可用性と信頼性に有害であると考えられています。
As an example, the Federal Office of Communications (OFCOM, Switzerland) provided statistics about emergency (112) calls in Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less emergency calls except for almost a month in July 2000 where a significant increase in hoax and test calls was reported. As a consequence, the functionality was disabled again. More details can be found in the panel presentations of the 3rd Standards Development Organization (SDO) Emergency Services Workshop [esw07].
例として、連邦通信局（OFCOM、スイス）は、1997年1月から2001年11月までのスイスでの緊急通報（112）に関する統計を提供しました。デマとテストの呼び出しの大幅な増加が報告された場所。その結果、機能が再び無効になりました。詳細については、第3標準開発機構（SDO）緊急サービスワークショップ[esw07]のパネルプレゼンテーションをご覧ください。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」 [RFC2119]で説明されているように解釈されます。
This document reuses terminology from [RFC5687] and [RFC5012], namely Internet Access Provider (IAP), Internet Service Provider (ISP), Application Service Provider (ASP), Voice Service Provider (VSP), Emergency Service Routing Proxy (ESRP), Public Safety Answering Point (PSAP), Location Configuration Server (LCS), (emergency) service dial string, and (emergency) service identifier.
このドキュメントでは、[RFC5687]と[RFC5012]の用語、つまりインターネットアクセスプロバイダー（IAP）、インターネットサービスプロバイダー（ISP）、アプリケーションサービスプロバイダー（ASP）、音声サービスプロバイダー（VSP）、緊急サービスルーティングプロキシ（ESRP）を再利用します。 Public Safety Answering Point（PSAP）、Location Configuration Server（LCS）、（緊急）サービスダイヤル文字列、および（緊急）サービス識別子。
An end host needs to perform the following steps if it is not attached to the network and the user is starting to place an emergency call:
エンドホストがネットワークに接続されておらず、ユーザーが緊急電話をかけ始めている場合、エンドホストは次の手順を実行する必要があります。
Link-Layer Attachment: Some networks have added support for unauthenticated emergency access while others have advertised these capabilities using layer beacons (multicast or broadcast announcements). The end host learns about these unauthenticated emergency services capabilities from either the link layer type or advertisement.
リンクレイヤーアタッチメント：一部のネットワークでは、認証されていない緊急アクセスのサポートが追加されていますが、レイヤービーコン（マルチキャストまたはブロードキャストアナウンス）を使用してこれらの機能をアドバタイズしているネットワークもあります。エンドホストは、リンクレイヤタイプまたはアドバタイズのいずれかから、これらの認証されていない緊急サービス機能について学習します。
The end host uses the link-layer-specific network attachment procedures defined for unauthenticated network access in order to get access to the network.
エンドホストは、認証されていないネットワークアクセス用に定義されたリンク層固有のネットワーク接続手順を使用して、ネットワークにアクセスします。
Pre-emergency Service Configuration: When the link-layer network attachment procedure is completed, the end host learns basic configuration information using DHCP from the ISP. The end host uses a Location Configuration Protocol (LCP) to retrieve location information. Subsequently, the LoST protocol [RFC5222] is used to learn the relevant emergency numbers and to obtain the PSAP URI applicable for that location.
緊急サービスの構成：リンク層ネットワーク接続手順が完了すると、エンドホストは、ISPからDHCPを使用して基本構成情報を学習します。エンドホストは、ロケーション構成プロトコル（LCP）を使用してロケーション情報を取得します。その後、LoSTプロトコル[RFC5222]を使用して、関連する緊急番号を学習し、その場所に適用可能なPSAP URIを取得します。
Emergency Call: In case of the need for help, a user dials an emergency number and the SIP User Agent (UA) initiates the emergency call procedures by communicating with the PSAP.
緊急コール：ヘルプが必要な場合、ユーザーは緊急番号をダイヤルし、SIPユーザーエージェント（UA）はPSAPと通信することによって緊急コール手順を開始します。
Figure 1 compiles the basic logic taking place during network entry for requesting an emergency service and shows the interrelation between the three conditions described earlier.
図1は、緊急サービスを要求するためのネットワークエントリ中に行われる基本的なロジックをまとめたもので、前述の3つの状態の相互関係を示しています。
+-----Y
|Start|
`...../
|
| Are credentials
| for network attachment
| available?
|
NO v YES
+----------------------------+
| |
| |
V v
.............. ................
| Idle: Wait | |Execute |
| for ES Call| |LLA Procedures|
| Initiation | "--------------'
"------------' |
Is | +---------->O
emergency | | | Is ASP
service | NO +-----Y | | configured?
network +--->| End | | +---------------+
attachment| `...../ | YES | | NO
possible? | | | |
v | v v
+------------+ | +------------+ +------------+
| Execute | | | Execute | | Execute |
| NAA |--------+ | Phone BCP | | NASP |
| Procedures | | Procedures | | Procedures |
+------------+ +------------+ +------------+
Authorization for| |
making an | |
emergency call | |
with the ASP/VSP?| |
+--------------+ v
| NO | YES +-----Y
| | | Done|
v v `...../
+------------+ +------------+
| Execute | | Execute |
| ZBP | | Phone BCP |
| Procedures | | Procedures |
+------------+ +------------+
| |
| |
v v
+-----Y +-----Y
| Done| | Done|
`...../ `...../
Abbreviations: LLA: Link-Layer Attachment ES: Emergency Services
略語：LLA：Link-Layer Attachment ES：緊急サービス
Figure 1: Flow Diagram: NAA, ZBP, and NSAP Scenarios
図1：フロー図：NAA、ZBP、およびNSAPシナリオ
The diagrams below highlight the most important steps for the three cases.
以下の図は、3つのケースの最も重要な手順を示しています。
+-----Y
|Start|
`...../
|
| No
| credentials
| for network access
| available
v
..............
| Idle: Wait |
| for ES Call|
| Initiation |
"------------'
|
|
|
v
--
// --
/ --
// Is --
/ emergency --
| service | NO +--------+
| network |------>| Call |
| attachment | Failed |
\ possible? / `......../
\ //
\\ //
\ //
\--/
|
| YES
|
|
v
+------------+
| Execute |
| NAA |
| Procedures |
+------------+
|
| Network
| attachment
| in progress
v
/--\ Continue
| | with
| | application-layer
\--/ interaction
Figure 2: Flow Diagram: NAA Scenario
図2：フロー図：NAAシナリオ
+-----+
+------------|Start|-----------------+
| `...../ |
v v
+------------+ +----------------+
| NAA | | Regular |
| Procedures | | Network Access |
+------------+ | Procedures |
| +----------------+
| |
| |
----------------o--------------------+
|
|
|
|
Network
Attachment
Completed
|
|
|
|
v
+------------+ +---------+
| ASP | NO | See |
| Configured?|----->| main |
+------------+ | diagram |
| `........./
|
| YES
|
v
//----
/ --
// --
/ - +---------+
| Authorization| YES | See |
| for making |------>| main |
| ES call | | diagram |
\ with / `........./
\ VSP/ASP? //
\\ //
\ //
\--/
|
| NO
|
|
v
+------------+
| Execute |
| ZBP |
| Procedures |
+------------+
|
| Call
| in progress
|
v
+--------+
| Call |
Success|
`......../
Figure 3: Flow Diagram: ZBP Scenario
図3：フロー図：ZBPシナリオ
+-----+
+------------|Start|-----------------+
| `...../ |
v v
+------------+ +----------------+
| NAA | | Regular |
| Procedures | | Network Access |
+------------+ | Procedures |
| +----------------+
| |
| |
----------------o--------------------+
|
|
|
|
Network
Attachment
Completed
|
|
|
|
v
+------------+ +---------+
| ASP | YES | See |
| Configured?|----->| main |
+------------+ | diagram |
| `........./
|
| NO
|
v
+------------+
| Execute |
| NASP |
| Procedures |
+------------+
|
| Call
| in progress
|
v
+--------+
| Call |
| Success|
`......../
Figure 4: Flow Diagram: NASP Scenario
The NAA procedures are described in Section 6. The ZBP procedures are described in Section 4. The NASP procedures are described in Section 5. The Phone BCP procedures are described in [RFC6881]. The LLA procedures are not described in this document since they are specific to the link-layer technology in use.
NAA手順はセクション6で説明されています。ZBP手順はセクション4で説明されています。NASP手順はセクション5で説明されています。電話BCP手順は[RFC6881]で説明されています。 LLA手順は、使用中のリンク層テクノロジーに固有であるため、このドキュメントでは説明していません。
ZBP includes all cases where a subscriber is known to an ASP but lacks the necessary authorization to access regular ASP services. Example ZBP cases include empty prepaid accounts, barred accounts, roaming and mobility restrictions, or any other conditions set by ASP policy.
ZBPには、加入者がASPに認識されているが、通常のASPサービスにアクセスするために必要な権限がないすべてのケースが含まれます。 ZBPの例には、空の前払いアカウント、禁止されたアカウント、ローミングとモビリティの制限、またはASPポリシーによって設定されたその他の条件が含まれます。
Local regulation might demand that emergency calls cannot proceed without successful service authorization. In some regulatory regimes, however, it may be possible to allow emergency calls to continue despite authorization failures. To distinguish an emergency call from a regular call, an ASP can identify emergency sessions by inspecting the service URN [RFC5031] used in call setup. The ZBP case, therefore, only affects the ASP.
地域の規制により、サービスの承認が成功しない限り、緊急通話を続行できないことが要求される場合があります。ただし、一部の規制制度では、承認に失敗しても緊急コールを継続できる場合があります。緊急コールを通常のコールと区別するために、ASPは、コールセットアップで使用されるサービスURN [RFC5031]を検査して緊急セッションを識別できます。したがって、ZBPのケースはASPにのみ影響します。
Permitting a call despite authorization failures could present an opportunity for abuse. The ASP may choose to verify the destination of the emergency calls and to only permit calls to certain, preconfigured entities (e.g., to local PSAPs). Section 7 discusses this topic in more detail.
認証に失敗しても通話を許可すると、悪用される可能性があります。 ASPは、緊急コールの宛先を検証し、特定の事前設定されたエンティティ（ローカルPSAPなど）へのコールのみを許可することを選択できます。セクション7では、このトピックについて詳しく説明します。
An ASP without a regulatory requirement to authorize emergency calls can deny emergency call setup. Where an ASP does not authorize an emergency call, the caller may be able to fall back to NASP procedures.
緊急コールを許可するための規制要件のないASPは、緊急コールのセットアップを拒否できます。 ASPが緊急コールを許可しない場合、発信者はNASP手順にフォールバックできる場合があります。
To start the description, we consider the sequence of steps that are executed in an emergency call based on Figure 5.
説明を始めるために、図5に基づいて、緊急通話で実行される一連のステップを検討します。
o As an initial step, the devices attach to the network as shown in step (1). This step is outside the scope of this section.
o 最初のステップとして、デバイスはステップ（1）に示すようにネットワークに接続します。この手順は、このセクションの範囲外です。
o When the link-layer network attachment procedure is completed, the end host learns basic IP configuration information using DHCP from the ISP, as shown in step (2).
o リンク層ネットワーク接続手順が完了すると、エンドホストは、手順（2）に示すように、ISPからDHCPを使用して基本的なIP構成情報を学習します。
o When the end host has configured the IP address, it starts an interaction with the discovered LCS at the ISP, as shown in step (3). In certain deployments, the ISP may need to interact with the IAP. This protocol exchange is shown in step (4).
o エンドホストがIPアドレスを構成すると、手順（3）に示すように、ISPで検出されたLCSとの対話が開始されます。特定の展開では、ISPがIAPと対話する必要がある場合があります。このプロトコル交換は、ステップ（4）に示されています。
o Once location information is obtained, the end host triggers the LoST protocol to obtain the address of the ESRP/PSAP. This is shown in step (5).
o 位置情報が取得されると、エンドホストはLoSTプロトコルをトリガーして、ESRP / PSAPのアドレスを取得します。これはステップ（5）に示されています。
o In step (6), the SIP UA initiates a SIP INVITE request towards the indicated ESRP. The INVITE message contains all the necessary parameters required by Section 5.1.5.
o ステップ（6）で、SIP UAは指定されたESRPに向けてSIP INVITE要求を開始します。 INVITEメッセージには、セクション5.1.5で必要なすべての必要なパラメータが含まれています。
o The ESRP receives the INVITE and processes it according to the description in Section 5.3.3.
o ESRPはINVITEを受信し、セクション5.3.3の説明に従ってそれを処理します。
o The ESRP routes the call to the PSAP, as shown in step (8), potentially interacting with a LoST server first to determine the route.
o ステップ（8）に示すように、ESRPはコールをPSAPにルーティングします。最初にLoSTサーバーと対話して、ルートを決定する可能性があります。
o The PSAP evaluates the initial INVITE and aims to complete the call setup.
o PSAPは最初のINVITEを評価し、コールセットアップを完了することを目的としています。
o Finally, when the call setup is completed, media traffic can be exchanged between the PSAP and the SIP UA.
o 最後に、コールセットアップが完了すると、PSAPとSIP UAの間でメディアトラフィックを交換できます。
For brevity, the end-to-end SIP and media exchange between the PSAP and SIP UA are not shown in Figure 5.
簡潔にするために、PSAPとSIP UAの間のエンドツーエンドのSIPおよびメディア交換は、図5には示されていません。
+-------+
| PSAP |
| |
+-------+
^
| (8)
|
+----------+(7) +----------+
| LoST |<-->| ESRP |
| Server | | |
+----------+ +----------+
^ ^
+----------------+----------------|--------------+
| ISP | | |
|+----------+ | | +----------+|
|| LCS-ISP | (3)| | | DHCP ||
|| |<-+ | | | Server ||
|+----------+ | | | +----------+|
+-------^------+-+----------------|-----------^--+
+-------|------+-+----------------|-----------|--+
| IAP | (4) | |(5) | | |
| V | | | | |
|+----------+ | | | | |
|| LCS-IAP | | | +--------+ | | |
|| | | | | Link- | |(6) | |
|+----------+ | | | Layer | | | |
| | | | Device | | (2)| |
| | | +--------+ | | |
| | | ^ | | |
| | | | | | |
+--------------+-|-------|--------|-----------|--+
| | | | |
| | (1)| | |
| | | | |
| | | +----+ |
| | v | |
| | +----------+ |
| +->| End |<-------------+
+___>| Host |
+----------+
Figure 5: Architectural Overview
図5：アーキテクチャの概要
Note: Figure 5 does not indicate who operates the ESRP and the LoST server. Various deployment options exist.
注：図5は、ESRPとLoSTサーバーの運用者を示しているわけではありません。さまざまな展開オプションがあります。
The end host MUST discover a LoST server [RFC5222] using DHCP [RFC5223] unless a LoST server has been provisioned using other means.
エンドホストは、LoSTサーバーが他の手段を使用してプロビジョニングされていない限り、DHCP [RFC5223]を使用してLoSTサーバー[RFC5222]を検出する必要があります。
The end host MUST discover the ESRP using the LoST protocol [RFC5222] unless a ESRP has been provisioned using other means.
エンドホストは、ESRPが他の手段を使用してプロビジョニングされていない限り、LoSTプロトコル[RFC5222]を使用してESRPを検出する必要があります。
The end host MUST support location acquisition and the LCPs described in Section 6.5 of [RFC6881]. The description in Sections 6.5 and 6.6 of [RFC6881] regarding the interaction between the device and the Location Information Server (LIS) applies to this document.
エンドホストは、[RFC6881]のセクション6.5で説明されている位置取得とLCPをサポートする必要があります。 [RFC6881]のセクション6.5と6.6にある、デバイスとLocation Information Server（LIS）間の相互作用に関する説明は、このドキュメントに適用されます。
The SIP UA in the end host MUST attach available location information in a Presence Information Data Format Location Object (PIDF-LO) [RFC4119] when making an emergency call. When constructing the PIDF-LO, the guidelines in the PIDF-LO profile [RFC5491] MUST be followed. For civic location information, the format defined in [RFC5139] MUST be supported.
エンドホストのSIP UAは、緊急コールを発信するときに、プレゼンス情報データフォーマットロケーションオブジェクト（PIDF-LO）[RFC4119]で利用可能なロケーション情報を添付する必要があります。 PIDF-LOを構築するときは、PIDF-LOプロファイル[RFC5491]のガイドラインに従う必要があります。市の位置情報については、[RFC5139]で定義されている形式をサポートする必要があります。
To determine which calls are emergency calls, some entity needs to map a user-entered dial string into this URN scheme. A user may "dial" 1-1-2, 9-1-1, etc., but the call would be sent to urn:service:sos. This mapping SHOULD be performed at the endpoint device.
一部のエンティティは、緊急コールであるコールを判別するために、ユーザーが入力したダイヤル文字列をこのURNスキームにマッピングする必要があります。ユーザーは1-1-2、9-1-1などに「ダイヤル」できますが、呼び出しはurn：service：sosに送信されます。このマッピングは、エンドポイントデバイスで実行する必要があります（SHOULD）。
End hosts MUST use the Service URN mechanism [RFC5031] to mark calls as emergency calls for their home emergency dial string.
エンドホストは、Service URNメカニズム[RFC5031]を使用して、ホームの緊急ダイヤル文字列の緊急コールとしてコールをマークする必要があります。
SIP signaling capabilities [RFC3261] are REQUIRED for end hosts.
エンドホストにはSIPシグナリング機能[RFC3261]が必要です。
The initial SIP signaling method is an INVITE. The SIP INVITE request MUST be constructed according to the requirements in Section 9.2 of [RFC6881].
最初のSIPシグナリング方式はINVITEです。 SIP INVITEリクエストは、[RFC6881]のセクション9.2の要件に従って作成する必要があります。
To enable callbacks, SIP UAs SHOULD place a globally routable URI in a Contact header field.
SIP UAは、コールバックを有効にするために、Contactヘッダーフィールドにグローバルにルーティング可能なURIを配置する必要があります（SHOULD）。
Endpoints MUST comply with the media requirements for endpoints placing an emergency call as described in Section 14 of [RFC6881].
エンドポイントは、[RFC6881]のセクション14で説明されているように、緊急通話を発信するエンドポイントのメディア要件に準拠する必要があります。
The description in Section 15 of [RFC6881] is fully applicable to this document.
[RFC6881]のセクション15の説明は、このドキュメントに完全に適用されます。
An ISP MUST provision a DHCP server with information about LoST servers [RFC5223]. An ISP operator may choose to deploy a LoST server or to outsource it to other parties.
ISPは、LoSTサーバーに関する情報をDHCPサーバーにプロビジョニングする必要があります[RFC5223]。 ISPオペレーターは、LoSTサーバーを展開するか、それを他の関係者に外部委託するかを選択できます。
The ISP is responsible for location determination and exposes this information to the endpoints via location configuration protocols. The considerations described in [RFC6444] are applicable to this document.
ISPはロケーションの決定を担当し、ロケーション構成プロトコルを介してこの情報をエンドポイントに公開します。 [RFC6444]で説明されている考慮事項は、このドキュメントに適用されます。
The ISP MUST support one of the LCPs described in Section 6.5 of [RFC6881]. The description in Sections 6.5 and 6.6 of [RFC6881] regarding the interaction between the end device and the LIS applies to this document.
ISPは、[RFC6881]のセクション6.5で説明されているLCPの1つをサポートする必要があります。エンドデバイスとLIS間の相互作用に関する[RFC6881]のセクション6.5および6.6の説明は、このドキュメントに適用されます。
The interaction between the LIS at the ISP and the IAP is often proprietary, but the description in [LIS] may be relevant to the reader.
多くの場合、ISPのLISとIAPの間のやり取りは独自仕様ですが、[LIS]の説明は読者に関連する場合があります。
The ESRP continues to route the emergency call to the PSAP responsible for the physical location of the end host. This may require further interactions with LoST servers but depends on the specific deployment.
ESRPは、エンドホストの物理的な場所を担当するPSAPに緊急コールをルーティングし続けます。これには、LoSTサーバーとのさらなる対話が必要になる場合がありますが、特定の展開によって異なります。
The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., the 'urn:service:sos' tree).
ESRPは、Service URNメカニズム[RFC5031]（つまり、「urn：service：sos」ツリー）を理解する必要があります。
SIP signaling capabilities [RFC3261] are REQUIRED for the ESRP. The ESRP MUST process the messages sent by the client, according to Section 5.1.5.
ESRPにはSIPシグナリング機能[RFC3261]が必要です。セクション5.1.5に従って、ESRPはクライアントから送信されたメッセージを処理する必要があります。
Furthermore, if a PSAP wants to support NASP calls, then it MUST NOT restrict incoming calls to a particular set of ASPs.
さらに、PSAPがNASP呼び出しをサポートしたい場合、着信呼び出しを特定のASPセットに制限してはなりません（MUST NOT）。
Some networks have added support for unauthenticated emergency access while others have advertised these capabilities using layer beacons. The end host learns about these unauthenticated emergency services capabilities either from the link-layer type or from advertisement.
認証されていない緊急アクセスのサポートを追加したネットワークもあれば、レイヤービーコンを使用してこれらの機能をアドバタイズしたネットワークもあります。エンドホストは、これらの認証されていない緊急サービス機能について、リンク層タイプまたはアドバタイズから学習します。
It is important to highlight that the NAA case is inherently a Layer 2 problem, and the general form of the solution is to provide an "emergency only" access type, with appropriate limits or monitoring to prevent abuse. The described mechanisms are informative in nature since the relationship to the IETF emergency services architecture is only indirect, namely via some protocols developed within the IETF (e.g., EAP and EAP methods) that require extensions to support this functionality.
NAAのケースは本質的にレイヤ2の問題であり、ソリューションの一般的な形式は、「緊急のみ」のアクセスタイプを提供し、乱用を防ぐために適切な制限または監視を行うことを強調することが重要です。 IETF緊急サービスアーキテクチャとの関係は間接的、つまりIETF内で開発された一部のプロトコル（EAPやEAPメソッドなど）を介してこの機能をサポートするために拡張を必要とするため、説明されているメカニズムは本質的に有益です。
This section discusses different methods to indicate an emergency service request as part of network attachment. It provides some general considerations and recommendations that are not specific to the access technology.
このセクションでは、緊急サービス要求をネットワーク接続の一部として示すためのさまざまな方法について説明します。アクセステクノロジーに固有ではない、いくつかの一般的な考慮事項と推奨事項を提供します。
To perform network attachment and get access to the resources provided by an IAP/ISP, the end host uses access technology-specific network attachment procedures, including, for example, network detection and selection, authentication, and authorization. For initial network attachment of an emergency service requester, the method of how the emergency indication is given to the IAP/ISP is specific to the access technology. However, a number of general approaches can be identified:
エンドホストは、ネットワーク接続を実行し、IAP / ISPが提供するリソースにアクセスするために、ネットワークの検出と選択、認証、承認など、アクセステクノロジー固有のネットワーク接続手順を使用します。緊急サービスリクエスタの初期ネットワークアタッチメントの場合、IAP / ISPに緊急指示を与える方法はアクセステクノロジーに固有です。ただし、いくつかの一般的なアプローチを確認できます。
Link-layer emergency indication: The end host provides an indication, e.g., an emergency parameter or flag, as part of the link-layer signaling for initial network attachment. Examples include an emergency bit signaled in the IEEE 802.16-2009 wireless link. In IEEE 802.11 WLAN [IEEE802.11], an emergency support indicator allows the station (i.e., end host in this context) to download before association to a Network Access Identifier (NAI), which it can use to request server-side authentication only for an IEEE 802.1X network.
リンク層の緊急表示：エンドホストは、初期ネットワーク接続のリンク層シグナリングの一部として、緊急パラメーターやフラグなどの表示を提供します。例としては、IEEE 802.16-2009ワイヤレスリンクで通知される緊急ビットがあります。 IEEE 802.11 WLAN [IEEE802.11]では、緊急サポートインジケータにより、ステーション（このコンテキストではエンドホスト）がネットワークアクセス識別子（NAI）に関連付ける前にダウンロードでき、サーバー側の認証のみを要求するために使用できます。 IEEE 802.1Xネットワークの場合。
Higher-layer emergency indication: Typically, emergency indication is provided in the network access authentication procedure. The emergency caller's end host provides an indication as part of the access authentication exchanges. Authentication via the EAP [RFC3748] is of particular relevance here. Examples are the EAP NAI decoration used in Worldwide Interoperability for Microwave Access (WiMAX) networks and modification of the authentication exchange in IEEE 802.11 [nwgstg3].
上位層の緊急表示：通常、緊急表示はネットワークアクセス認証手順で提供されます。緊急発信者のエンドホストは、アクセス認証交換の一部として表示を提供します。 EAP [RFC3748]による認証は、ここでは特に重要です。例としては、マイクロウェーブアクセス（WiMAX）ネットワークのワールドワイド相互運用性で使用されるEAP NAI装飾、およびIEEE 802.11 [nwgstg3]での認証交換の変更があります。
In general, link-layer emergency indications provide good integration into the actual network access procedure regarding the enabling of means to recognize and prioritize an emergency service request from an end host at a very early stage of the network attachment procedure. However, support in end hosts for such methods cannot be considered to be commonly available.
一般に、リンク層の緊急表示は、ネットワーク接続手順の非常に早い段階でエンドホストからの緊急サービス要求を認識して優先順位を付ける手段の有効化に関して、実際のネットワークアクセス手順に適切に統合されます。ただし、このような方法のエンドホストでのサポートは、一般に利用可能であるとは見なされません。
No general recommendations are given in the scope of this memo due to the following reasons:
以下の理由により、このメモの範囲では一般的な推奨事項はありません。
o Dependency on the specific access technology.
o 特定のアクセス技術への依存。
o Dependency on the specific access network architecture. Access authorization and policy decisions typically happen at different layers of the protocol stack and in different entities than those terminating the link-layer signaling. As a result, link-layer indications need to be distributed and translated between the different protocol layers and entities involved. Appropriate methods are specific to the actual architecture of the IAP/ISP network.
o 特定のアクセスネットワークアーキテクチャへの依存。アクセス許可とポリシーの決定は、通常、プロトコルスタックの異なるレイヤーで、リンク層のシグナリングを終了するエンティティとは異なるエンティティで行われます。その結果、リンク層の表示は、関係するさまざまなプロトコル層とエンティティの間で分散および変換される必要があります。適切な方法は、IAP / ISPネットワークの実際のアーキテクチャに固有です。
o An advantage of combining emergency indications with the actual network attachment procedure performing authentication and authorization is the fact that the emergency indication can directly be taken into account in the authentication and authorization server that owns the policy for granting access to the network resources. As a result, there is no direct dependency on the access network architecture that otherwise would need to take care of merging link-layer indications into the authentication, authorization, and policy decision process.
o 緊急表示を、認証と承認を実行する実際のネットワーク接続手順と組み合わせる利点は、ネットワークリソースへのアクセスを許可するポリシーを所有する認証および承認サーバーで緊急表示を直接考慮できることです。その結果、リンク層の表示を認証、承認、およびポリシー決定プロセスにマージする必要があるアクセスネットワークアーキテクチャに直接依存することはありません。
o EAP signaling happens at a relatively early stage of network attachment, so it is likely to match most requirements for prioritization of emergency signaling. However, it does not cover early stages of link-layer activity in the network attachment process. Possible conflicts may arise, e.g., in case of filtering based on Media Access Control (MAC) in entities terminating link-layer signaling in the network (like a base station). In normal operation, EAP-related information will only be recognized in the Network Access Server (NAS). Any entity residing between the end host and NAS should not be expected to understand/parse EAP messages.
o EAPシグナリングはネットワーク接続の比較的早い段階で発生するため、緊急シグナリングの優先順位付けに関するほとんどの要件に一致する可能性があります。ただし、ネットワーク接続プロセスのリンク層アクティビティの初期段階は対象外です。たとえば、ネットワーク内のリンク層シグナリングを終了するエンティティ（基地局など）でメディアアクセス制御（MAC）に基づいてフィルタリングする場合、競合が発生する可能性があります。通常の操作では、EAP関連の情報はネットワークアクセスサーバー（NAS）でのみ認識されます。エンドホストとNASの間に存在するエンティティは、EAPメッセージを理解/解析することを期待されるべきではありません。
o An emergency indication can be given by forming a specific NAI that is used as the identity in EAP-based authentication for network entry.
o 緊急表示は、ネットワークエントリのEAPベースの認証でIDとして使用される特定のNAIを形成することによって提供できます。
For network attachment in NAA cases, it may make sense to secure the link-layer connection between the device and the IAP/ISP. This especially holds for wireless access with examples being access based on IEEE 802.11 or IEEE 802.16. The latter even mandates secured communication across the wireless link for all IAP/ISP networks based on [nwgstg3].
NAAの場合のネットワーク接続の場合、デバイスとIAP / ISPの間のリンク層接続を保護することは理にかなっています。これは特に、IEEE 802.11またはIEEE 802.16に基づくアクセスを例とするワイヤレスアクセスに当てはまります。後者は、[nwgstg3]に基づくすべてのIAP / ISPネットワークの無線リンクを介した安全な通信を義務付けています。
Therefore, for network attachment that is by default based on EAP authentication, it is desirable also for NAA network attachment to use a key-generating EAP method (that provides a Master Session Key (MSK) to the authenticator to bootstrap further key derivation for protecting the wireless link).
したがって、デフォルトでEAP認証に基づくネットワークアタッチメントの場合、NAAネットワークアタッチメントは、キー生成EAPメソッド（マスターセッションキー（MSK）をオーセンティケーターに提供して、保護のためのさらなるキー派生をブートストラップする）を使用することも望ましいワイヤレスリンク）。
To match the above, the following approaches can be identified:
上記と一致するように、次のアプローチを特定できます。
1) Server-Only Authentication:
1）サーバーのみの認証：
The device of the emergency service requester performs an EAP method with the IAP/ISP EAP server that performs server-side authentication only. An example for this is EAP-TLS [RFC5216]. This provides a certain level of assurance about the IAP/ISP to the device user. It requires the device to be provisioned with appropriate trusted root certificates to be able to verify the server certificate of the EAP server (unless this step is explicitly skipped in the device in case of an emergency service request). This method is used to provide access of devices without existing credentials to an IEEE 802.1X network. The details are incorporated in the IEEE 802.11-2012 specification [IEEE802.11].
緊急サービスリクエスタのデバイスは、サーバー側の認証のみを実行するIAP / ISP EAPサーバーでEAPメソッドを実行します。この例は、EAP-TLS [RFC5216]です。これにより、デバイスユーザーにIAP / ISPに関する一定レベルの保証が提供されます。 EAPサーバーのサーバー証明書を検証できるようにするには、デバイスに適切な信頼されたルート証明書をプロビジョニングする必要があります（緊急サービス要求の場合にデバイスでこの手順が明示的にスキップされない限り）。この方法は、IEEE 802.1Xネットワークへの既存の資格情報なしでデバイスのアクセスを提供するために使用されます。詳細は、IEEE 802.11-2012仕様[IEEE802.11]に組み込まれています。
2) Null Authentication:
2）ヌル認証：
In one case (e.g., WiMAX), an EAP method is performed. However, no credentials specific to either the server or the device or subscription are used as part of the authentication exchange. An example for this would be an EAP-TLS exchange using the TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly available static key for emergency access could be used. In the latter case, the device would need to be provisioned with the appropriate emergency key for the IAP/ISP in advance. In another case (e.g., IEEE 802.11), no EAP method is used, so that empty frames are transported during the over-the-air IEEE 802.1X exchange. In this case, the authentication state machine completes with no cryptographic keys being exchanged.
１つのケース（例えば、ＷｉＭＡＸ）では、ＥＡＰメソッドが実行される。ただし、サーバーまたはデバイスまたはサブスクリプションに固有の資格情報は、認証交換の一部として使用されません。この例は、TLS_DH_anon（匿名）暗号スイートを使用したEAP-TLS交換です。または、緊急アクセス用の公開されている静的キーを使用することもできます。後者の場合、デバイスには事前にIAP / ISPの適切な緊急キーをプロビジョニングする必要があります。別のケース（IEEE 802.11など）では、EAP方式が使用されないため、空中のIEEE 802.1X交換中に空のフレームが転送されます。この場合、認証状態マシンは、暗号鍵が交換されることなく完了します。
3) Device Authentication:
3）デバイス認証：
This case extends the server-only authentication case. If the device is configured with a device certificate and the IAP/ISP EAP server can rely on a trusted root allowing the EAP server to verify the device certificate, at least the device identity (e.g., the MAC address) can be authenticated by the IAP/ISP in NAA cases. An example for this is WiMAX devices that are shipped with device certificates issued under the global WiMAX device public-key infrastructure. To perform unauthenticated emergency calls, if allowed by the IAP/ISP, such devices perform network attachment based on EAP-TLS with client authentication based on the device certificate.
このケースは、サーバーのみの認証ケースを拡張します。デバイスにデバイス証明書が構成されていて、IAP / ISP EAPサーバーが信頼されたルートに依存して、EAPサーバーがデバイス証明書を確認できる場合、少なくともデバイスID（MACアドレスなど）をIAPで認証できます。 NAAの場合の/ ISP。この例は、グローバルWiMAXデバイスの公開キーインフラストラクチャの下で発行されたデバイス証明書と共に出荷されるWiMAXデバイスです。 IAP / ISPで許可されている場合、認証されていない緊急コールを実行するために、そのようなデバイスは、デバイス証明書に基づくクライアント認証を使用して、EAP-TLSに基づくネットワーク接続を実行します。
The security threats discussed in [RFC5069] are applicable to this document.
[RFC5069]で説明されているセキュリティの脅威は、このドキュメントに適用されます。
The NASP and NAA cases introduce new vulnerabilities since the PSAP operator will typically not have any information about the identity of the caller via the signaling path. Today, in countries where this functionality is used for Global System for Mobile Communications (GSM) networks, this has lead to a significant amount of misuse.
PSAPオペレーターは通常、シグナリングパスを介して発信者のIDに関する情報を持たないため、NASPとNAAのケースは新しい脆弱性をもたらします。現在、この機能がグローバルシステムモバイルコミュニケーション（GSM）ネットワークに使用されている国では、これによりかなりの誤用が生じています。
In the context of NAA, the IAP and the ISP will probably want to make sure that the claimed emergency caller indeed performs an emergency call rather than using the network for other purposes, and thereby acting fraudulent by skipping any authentication, authorization, and accounting procedures. By restricting access of the unauthenticated emergency caller to the LoST server and the PSAP URI, traffic can be restricted only to emergency calls. This can be accomplished with traffic separation. However, the details, e.g., for using filtering, depend on the deployed ISP architecture and are beyond the scope of this document.
NAAのコンテキストでは、IAPとISPはおそらく、主張された緊急発信者がネットワークを他の目的で使用するのではなく、実際に緊急コールを実行することを確認し、それによって認証、承認、およびアカウンティング手順をスキップすることによって詐欺行為を行います。 。認証されていない緊急発信者のLoSTサーバーとPSAP URIへのアクセスを制限することで、トラフィックを緊急通話のみに制限できます。これは、トラフィックを分離することで実現できます。ただし、フィルタリングの使用などの詳細は、展開されているISPアーキテクチャによって異なり、このドキュメントの範囲を超えています。
We only illustrate a possible model. If the ISP runs its own (caching) LoST server, the ISP would maintain an access control list populated with IP-address information obtained from LoST responses (in the mappings). These URIs would either be URIs for contacting further LoST servers or PSAP URIs. It may be necessary to translate domain names returned in LoST responses to IP addresses. Since the media destination addresses are not predictable, the ISP also has to provide a SIP outbound proxy so that it can determine the media addresses and add those to the filter list.
可能なモデルのみを示します。 ISPが独自の（キャッシング）LoSTサーバーを実行している場合、ISPは、（マッピング内の）LoST応答から取得したIPアドレス情報が入力されたアクセス制御リストを維持します。これらのURIは、さらにLoSTサーバーに接続するためのURIまたはPSAP URIのいずれかになります。 LoST応答で返されたドメイン名をIPアドレスに変換する必要がある場合があります。メディアの宛先アドレスは予測できないため、ISPはSIPアウトバウンドプロキシを提供して、メディアアドレスを特定し、フィルターリストに追加できるようにする必要があります。
For the ZBP case, the additional aspect of fraud has to be considered. Unless the emergency call traverses a PSTN gateway or the ASP charges for IP-to-IP calls, there is little potential for fraud. If the ASP also operates the LoST server, the outbound proxy MAY restrict outbound calls to the SIP URIs returned by the LoST server. It is NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may change.
ZBPの場合、詐欺の追加の側面を考慮する必要があります。緊急コールがPSTNゲートウェイを通過しないか、ASPがIP-to-IPコールに課金しない限り、詐欺の可能性はほとんどありません。 ASPがLoSTサーバーも操作する場合、アウトバウンドプロキシは、LoSTサーバーから返されたSIP URIへのアウトバウンドコールを制限してもよい（MAY）。リストが変更される可能性があるため、SIP URIの固定リストに依存することはお勧めしません。
RFC 6280 [RFC6280] discusses security vulnerabilities that are caused by an adversary faking location information and thereby lying about the actual location of the emergency caller. These threats may be less problematic in the context of an unauthenticated emergency when location information can be verified by the ISP to fall within a specific geographical area.
RFC 6280 [RFC6280]は、敵の位置情報の偽造によって引き起こされ、それによって緊急の発信者の実際の位置について嘘をついているセキュリティの脆弱性について説明しています。これらの脅威は、認証されていない緊急事態において、ISPによって位置情報が特定の地理的領域内にあることが確認できる場合には、問題が少なくなる可能性があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3261] 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, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005, <http://www.rfc-editor.org/info/rfc4119>.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、2005年12月、<http://www.rfc-editor.org/info/rfc4119>。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008, <http://www.rfc-editor.org/info/rfc5031>.
[RFC5031] Schulzrinne、H。、「緊急およびその他の既知のサービスのためのUniform Resource Name（URN）」、RFC 5031、2008年1月、<http://www.rfc-editor.org/info/rfc5031>。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008, <http://www.rfc-editor.org/info/rfc5139>.
[RFC5139] Thomson、M.、J。Winterbottom、「Resive Civic Location Format for Presence Information Data Format Location Object（PIDF-LO）」、RFC 5139、2008年2月、<http://www.rfc-editor.org/ info / rfc5139>。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008, <http://www.rfc-editor.org/info/rfc5222>.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「LoST：A Location-to-Service Translation Protocol」、RFC 5222、2008年8月、<http：//www.rfc -editor.org/info/rfc5222>。
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008, <http://www.rfc-editor.org/info/rfc5223>.
[RFC5223] Schulzrinne、H.、Polk、J。、およびH. Tschofenig、「Discovering Location-to-Service Translation（LoST）Servers using the Dynamic Host Configuration Protocol（DHCP）」、RFC 5223、2008年8月、<http： //www.rfc-editor.org/info/rfc5223>。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009, <http://www.rfc-editor.org/info/rfc5491>.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「GEOPRIV Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、2009年3月、<http：/ /www.rfc-editor.org/info/rfc5491>。
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, March 2013, <http://www.rfc-editor.org/info/rfc6881>.
[RFC6881]ローゼンB.およびJ.ポーク、「緊急通話をサポートする通信サービスの現在のベストプラクティス」、BCP 181、RFC 6881、2013年3月、<http://www.rfc-editor.org/info/ rfc6881>。
[IEEE802.11] IEEE, "IEEE Standard for Information Technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, March 2012, <http://standards.ieee.org/about/get/802/802.11.html>.
[IEEE802.11] IEEE、「IEEE Standard for Information Technology-Telecommunications and information exchange between system-Local and metropolitan area network-Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、IEEE Std 802.11-2012、2012年3月、<http://standards.ieee.org/about/get/802/802.11.html>。
[LIS] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol Requirements", Work in Progress, draft-winterbottom-geopriv-lis2lis-req-01, November 2007.
[LIS] Winterbottom、J。およびS. Norreys、「LIS to LIS Protocol Requirements」、Work in Progress、draft-winterbottom-geopriv-lis2lis-req-01、2007年11月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月、<http：// www。 rfc-editor.org/info/rfc3748>。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008, <http://www.rfc-editor.org/info/rfc5012>.
[RFC5012] Schulzrinne、H。およびR. Marshall、「Requirements for Emergency Context Resolution with Internet Technologies」、RFC 5012、2008年1月、<http://www.rfc-editor.org/info/rfc5012>。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008, <http://www.rfc-editor.org/info/rfc5069>.
[RFC5069] Taylor、T.、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「セキュリティ上の脅威と緊急通話のマーキングとマッピングの要件」、RFC 5069、2008年1月、<http：//www.rfc -editor.org/info/rfc5069>。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5216]サイモン、D。、アボバ、B。、およびR.ハースト、「EAP-TLS認証プロトコル」、RFC 5216、2008年3月、<http://www.rfc-editor.org/info/rfc5216> 。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010, <http://www.rfc-editor.org/info/rfc5687>.
[RFC5687] Tschofenig、H。およびH. Schulzrinne、「GEOPRIV Layer 7 Location Configuration Protocol：Problem Statement and Requirements」、RFC 5687、2010年3月、<http://www.rfc-editor.org/info/rfc5687>。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011, <http://www.rfc-editor.org/info/rfc6280>.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月、<http://www.rfc-editor.org/info/rfc6280>。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6443] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「Framework for Emergency Calling Using Internet Multimedia」、RFC 6443、2011年12月、<http：//www.rfc-editor。 org / info / rfc6443>。
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. Kuett, "Location Hiding: Problem Statement and Requirements", RFC 6444, January 2012, <http://www.rfc-editor.org/info/rfc6444>.
[RFC6444] Schulzrinne、H.、Liess、L.、Tschofenig、H.、Stark、B。、およびA. Kuett、「Location Hiding：Problem Statement and Requirements」、RFC 6444、2012年1月、<http：// www .rfc-editor.org / info / rfc6444>。
[esw07] "3rd Standards Development Organziations (SDO) Emergency Services Workshop", October 30th - November 1st 2007, <http://www.emergency-services-coordination.info/2007Nov/>.
[esw07]「第3標準開発組織（DO）緊急サービスワークショップ」、2007年10月30日〜11月1日、<http://www.emergency-services-coordination.info/2007Nov/>。
[nwgstg3] WiMAX Forum, "WiMAX Forum Network Architecture - Detailed Protocols and Procedures Base Specification", Stage-3 WMF-T33-001-R022V02, April 2014, <http://resources.wimaxforum. org/sites/wimaxforum.org/files/technical_document/2014/05/ WMF-T33-001-R022v02_Network-Stage3-Base.pdf>.
[nwgstg3] WiMAXフォーラム、「WiMAXフォーラムネットワークアーキテクチャ-詳細なプロトコルと手順の基本仕様」、ステージ3 WMF-T33-001-R022V02、2014年4月、<http：//resources.wimaxforum。 org / sites / wimaxforum.org / files / technical_document / 2014/05 / WMF-T33-001-R022v02_Network-Stage3-Base.pdf>。
Acknowledgments
謝辞
Parts of this document are derived from [RFC6881]. Participants of the 2nd and 3rd SDO Emergency Services Workshop provided helpful input.
このドキュメントの一部は、[RFC6881]から派生しています。第2および第3 SDO緊急サービスワークショップの参加者は、有益な情報を提供しました。
We would like to thank Richard Barnes, Marc Linsner, James Polk, Brian Rosen, and Martin Thomson for their feedback at the IETF#80 Emergency Context Resolution with Internet Technology (ECRIT) meeting.
IETF＃80 Emergency Context Resolution with Internet Technology（ECRIT）ミーティングでのフィードバックについて、Richard Barnes、Marc Linsner、James Polk、Brian Rosen、およびMartin Thomsonに感謝します。
Furthermore, we would like to thank Martin Thomson and Bernard Aboba for their detailed document review in preparation of the 81st IETF meeting. Alexey Melnikov was the General Area (Gen-Art) reviewer. A number of changes to the document had been made in response to the AD review by Richard Barnes.
さらに、第81回IETF会議に向けての詳細なドキュメントレビューを提供してくれたMartin ThomsonとBernard Abobaに感謝します。 Alexey Melnikovは、一般的な領域（Gen-Art）のレビューアでした。 Richard BarnesによるADのレビューに応じて、ドキュメントに多くの変更が加えられました。
Various IESG members provided review comments, including Spencer Dawkins, Stephen Farrell, Joel Jaeggli, Barry Leiba, Ted Lemon, and Pete Resnick.
スペンサードーキンス、スティーブンファレル、ジョエルジャグリ、バリーレイバ、テッドレモン、ピートレズニックなど、さまざまなIESGメンバーがレビューコメントを提供しました。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 United States
ヘニングシュルズリンネコロンビア大学コンピュータサイエンス学科450コンピュータサイエンスビルディングニューヨーク、ニューヨーク10027アメリカ合衆国
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Stephen McCann BlackBerry Ltd 200 Bath Road Slough, Berks SL1 3XE United Kingdom
Stephen McCann BlackBerry Ltd 200 Bath Road Slough、Berks SL1 3XEイギリス
Phone: +44 1753 667099
EMail: smccann@blackberry.com
URI: http://www.blackberry.com
Gabor Bajko MediaTek
Gabor Bajko MediaTek
EMail: gabor.bajko@mediatek.com
Hannes Tschofenig Hall in Tirol 6060 Austria
Hannes Tschofenig Hall in Tirol 6060オーストリア
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Dirk Kroeselberg Siemens Corporate Technology Otto-Hahn-Ring 6 Munich 81739 Germany
Dirk Kroeselberg Siemens Corporate Technology Otto-Hahn-Ring 6ミュンヘン81739ドイツ
EMail: dirk.kroeselberg@siemens.com