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
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.Kroeselberg西门子公司技术部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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
在紧急情况下召集警察、消防部门或救护车是电话最基本和最有价值的功能之一。随着电话功能从电路交换电话转移到互联网电话，其用户理所当然地期望该核心功能将继续工作，至少与旧技术一样。正在提供可用于请求帮助的新设备和服务；这些设备不是传统电话，用户越来越希望它们能够拨打紧急电话。
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信令功能。紧急呼叫方可以直接或通过ASP的出站代理到达ESN。三方中的任何一方都可以通过提供位置到服务转换（LoST）[RFC5222]服务，提供从位置到公共安全应答点（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时支持紧急呼叫，则一个或多个提供商可能需要提供附加服务和功能。
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.
在所有情况下，终端设备必须能够执行丢失查找，并以与下述三种例外情况不适用时相同的方式进行紧急呼叫。
We distinguish among three conditions:
我们区分三种情况：
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.
这三种情况并不相互排斥。例如，需要帮助的呼叫者可能同时处于NAA和NASP状态，如图1所示。根据当地政策和法规，可能无法在NAA情况下拨打紧急电话。除非当地法规要求用户识别，否则应始终能够在NASP情况下拨打电话，对ISP的影响最小。除非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）的统计数据。瑞士没有提供无SIM卡的紧急呼叫，但2000年7月有近一个月的时间，据报道，骗局和测试呼叫显著增加。因此，该功能再次被禁用。更多详细信息，请参见第三届标准发展组织（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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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）、公共安全应答点（PSAP）、位置配置服务器（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.
应急前服务配置：当链路层网络连接程序完成时，终端主机使用DHCP从ISP学习基本配置信息。终端主机使用位置配置协议（LCP）检索位置信息。随后，使用丢失协议[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汇总了网络进入期间请求紧急服务的基本逻辑，并显示了前面描述的三种情况之间的相互关系。
+-----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
+-----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|
`...../ `...../
+------------+ | +------------+ +------------+
| 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：链路层附件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.
下图强调了这三种情况下最重要的步骤。
+-----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 |
+------------+
+-----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
|
| 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
+-----+
+------------|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|
`......../
+------------+ +---------+
| 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
+-----+
+------------|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节。第4节介绍了ZBP程序。NASP程序见第5节。[RFC6881]中描述了电话BCP程序。由于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 链路层网络连接过程完成后，终端主机使用DHCP从ISP学习基本IP配置信息，如步骤（2）所示。
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地址后，它将开始与ISP上发现的LCS进行交互，如步骤（3）所示。在某些部署中，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 一旦获得位置信息，终端主机将触发丢失协议以获取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接收邀请并根据第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 ESRP将调用路由到PSAP，如步骤（8）所示，可能首先与丢失的服务器交互以确定路由。
o The PSAP evaluates the initial INVITE and aims to complete the call setup.
o PSAP评估初始邀请并旨在完成呼叫设置。
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.
为简洁起见，图5中未显示PSAP和SIP UA之间的端到端SIP和媒体交换。
+-------+
| 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 |
+----------+
+-------+
| 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和丢失的服务器。存在各种部署选项。
The end host MUST discover a LoST server [RFC5222] using DHCP [RFC5223] unless a LoST server has been provisioned using other means.
终端主机必须使用DHCP[RFC5223]发现丢失的服务器[RFC5222]，除非已使用其他方式配置丢失的服务器。
The end host MUST discover the ESRP using the LoST protocol [RFC5222] unless a ESRP has been provisioned using other means.
终端主机必须使用丢失协议[RFC5222]发现ESRP，除非已使用其他方式配置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节中关于设备和位置信息服务器（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。此映射应在端点设备上执行。
End hosts MUST use the Service URN mechanism [RFC5031] to mark calls as emergency calls for their home emergency dial string.
终端主机必须使用服务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 UAs应在联系人标头字段中放置一个全局可路由URI。
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必须为DHCP服务器提供有关丢失服务器的信息[RFC5223]。ISP运营商可以选择部署丢失的服务器或将其外包给其他方。
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之一。[RFC6881]第6.5节和第6.6节中关于终端设备和LIS之间交互的描述适用于本文件。
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。这可能需要与丢失的服务器进行进一步的交互，但具体取决于具体的部署。
The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., the 'urn:service:sos' tree).
ESRP必须了解服务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]。ESRP必须根据第5.1.5节处理客户发送的消息。
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。
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
o EAP信令发生在网络连接的相对早期阶段，因此它可能符合紧急信令优先级的大多数要求。但是，它不包括
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.
网络连接过程中链路层活动的早期阶段。例如，在终止网络中的链路层信令的实体（如基站）中基于媒体访问控制（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 可以通过形成特定的NAI来给出紧急指示，该NAI在基于EAP的网络进入认证中用作身份。
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.
在一种情况下（例如，WiMAX），执行EAP方法。但是，没有特定于服务器、设备或订阅的凭据用作身份验证交换的一部分。例如，使用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服务器验证设备证书，则在NAA情况下，IAP/ISP至少可以对设备标识（例如MAC地址）进行身份验证。这方面的一个例子是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.
NASP和NAA案例引入了新的漏洞，因为PSAP运营商通常不会通过信令路径获得关于呼叫方身份的任何信息。今天，在全球移动通信系统（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,
在NAA的情况下，IAP和ISP可能希望确保声称的紧急呼叫者确实执行紧急呼叫，而不是将网络用于其他目的，从而通过跳过任何身份验证、授权和记帐程序来进行欺诈。通过限制未经身份验证的紧急呼叫方对丢失的服务器和PSAP URI的访问，通信量可以仅限于紧急呼叫。这可以通过交通隔离来实现。然而，细节，例如，使用过滤，
depend on the deployed ISP architecture and are beyond the scope of this document.
取决于已部署的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运行自己的（缓存）丢失的服务器，ISP将维护一个访问控制列表，其中包含从丢失的响应（在映射中）获得的IP地址信息。这些URI可以是用于联系进一步丢失的服务器的URI，也可以是PSAP URI。可能需要将丢失响应中返回的域名转换为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到IP呼叫收费，否则欺诈的可能性很小。如果ASP还操作丢失的服务器，则出站代理可能会限制对丢失的服务器返回的SIP URI的出站调用。不建议依赖固定的SIPURI列表，因为该列表可能会更改。
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：会话启动协议”，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.，“基于状态的GEOPRIV定位对象格式”，RFC41192005年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.，“应急和其他知名服务的统一资源名称（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，“状态信息数据格式位置对象（PIDF-LO）的修订公民位置格式”，RFC 51392008年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，“丢失：位置到服务转换协议”，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，“使用动态主机配置协议（DHCP）发现位置到服务转换（丢失）服务器”，RFC 52232008年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存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”，RFC 54912009年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]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务最佳现行实践”，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信息技术标准-系统间电信和信息交换-局域网和城域网-特定要求第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准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到LIS协议要求”，正在进行的工作，草稿-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，“可扩展身份验证协议（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，“利用互联网技术解决紧急情况的要求”，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]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 52162008年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第7层位置配置协议：问题陈述和要求”，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，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年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，“使用互联网多媒体进行紧急呼叫的框架”，RFC 64432011年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，“位置隐藏：问题陈述和要求”，RFC 64442012年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]“第三届标准制定组织（SDO）应急服务研讨会”，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论坛网络架构-详细协议和程序基础规范”，第三阶段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]。第二次和第三次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.
我们要感谢Richard Barnes、Marc Linsner、James Polk、Brian Rosen和Martin Thomson在IETF#80紧急上下文解决与互联网技术（ECRIT）会议上的反馈。
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.
此外，我们还要感谢Martin Thomson和Bernard Aboba为筹备第81届IETF会议所作的详细文件审查。Alexey Melnikov是一般领域（Gen Art）的评审员。理查德·巴恩斯（Richard Barnes）的广告评论对该文件进行了一些修改。
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
Henning Schulzrinne哥伦比亚大学计算机科学系，美国纽约州纽约市计算机科学大楼450号，邮编10027
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
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
斯蒂芬·麦肯黑莓有限公司，英国伯克斯州巴斯路斯洛200号SL1 3XE
Phone: +44 1753 667099
EMail: smccann@blackberry.com
URI: http://www.blackberry.com
Phone: +44 1753 667099
EMail: smccann@blackberry.com
URI: http://www.blackberry.com
Gabor Bajko MediaTek
加博·巴伊科·梅迪塔克
EMail: gabor.bajko@mediatek.com
EMail: gabor.bajko@mediatek.com
Hannes Tschofenig Hall in Tirol 6060 Austria
奥地利蒂罗尔的汉内斯·茨霍芬尼大厅6060
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Dirk Kroeselberg Siemens Corporate Technology Otto-Hahn-Ring 6 Munich 81739 Germany
德克·克罗塞尔伯格西门子公司技术奥托·哈恩环6慕尼黑81739德国
EMail: dirk.kroeselberg@siemens.com
EMail: dirk.kroeselberg@siemens.com