Internet Engineering Task Force (IETF) H. Tschofenig
Request for Comments: 7378 Independent
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia University
B. Aboba, Ed.
Microsoft Corporation
December 2014
Internet Engineering Task Force (IETF) H. Tschofenig
Request for Comments: 7378 Independent
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia University
B. Aboba, Ed.
Microsoft Corporation
December 2014
Trustworthy Location
可靠位置
Abstract
摘要
The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.
对于一些基于位置的应用，如紧急呼叫或路边救援，位置信息的可信度至关重要。
This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.
本文档描述了传输位置信息（尤其是紧急呼叫）面临的威胁，并描述了提高位置信息可靠性和安全性的技术。它还提供了评估位置信息可信度的指南。
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/rfc7378.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7378.
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
1.1. Terminology ................................................3
1.2. Emergency Services Architecture ............................5
2. Threat Models ...................................................8
2.1. Existing Work ..............................................8
2.2. Adversary Model ............................................9
2.3. Location Spoofing .........................................10
2.4. Identity Spoofing .........................................11
3. Mitigation Techniques ..........................................11
3.1. Signed Location-by-Value ..................................12
3.2. Location-by-Reference .....................................15
3.3. Proxy-Added Location ......................................18
4. Location Trust Assessment ......................................20
5. Security Considerations ........................................23
6. Privacy Considerations .........................................24
7. Informative References .........................................26
Acknowledgments ...................................................30
Authors' Addresses ................................................30
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Emergency Services Architecture ............................5
2. Threat Models ...................................................8
2.1. Existing Work ..............................................8
2.2. Adversary Model ............................................9
2.3. Location Spoofing .........................................10
2.4. Identity Spoofing .........................................11
3. Mitigation Techniques ..........................................11
3.1. Signed Location-by-Value ..................................12
3.2. Location-by-Reference .....................................15
3.3. Proxy-Added Location ......................................18
4. Location Trust Assessment ......................................20
5. Security Considerations ........................................23
6. Privacy Considerations .........................................24
7. Informative References .........................................26
Acknowledgments ...................................................30
Authors' Addresses ................................................30
Several public and commercial services need location information to operate. This includes emergency services (such as fire, ambulance, and police) as well as commercial services such as food delivery and roadside assistance.
一些公共和商业服务需要位置信息才能运行。这包括紧急服务（如消防、救护车和警察）以及商业服务，如食品配送和路边救援。
For circuit-switched calls from landlines, as well as for Voice over IP (VoIP) services that only support emergency service calls from stationary Devices, location provided to the Public Safety Answering Point (PSAP) is determined from a lookup using the calling telephone number. As a result, for landlines or stationary VoIP, spoofing of caller identification can result in the PSAP incorrectly determining the caller's location. Problems relating to calling party number and Caller ID assurance have been analyzed by the Secure Telephone Identity Revisited [STIR] working group as described in "Secure Telephone Identity Problem Statement and Requirements" [RFC7340]. In addition to the work underway in STIR, other mechanisms exist for validating caller identification. For example, as noted in [EENA], one mechanism for validating caller identification information (as well as the existence of an emergency) is for the PSAP to call the user back, as described in [RFC7090].
对于来自固定线路的电路交换呼叫，以及仅支持来自固定设备的紧急服务呼叫的IP语音（VoIP）服务，提供给公共安全应答点（PSAP）的位置通过使用呼叫电话号码的查找来确定。因此，对于固定电话或固定VoIP，对呼叫者身份的欺骗可能导致PSAP错误地确定呼叫者的位置。如“安全电话身份问题声明和要求”[RFC7340]所述，安全电话身份重访[STIR]工作组已分析了与主叫方号码和主叫方ID保证相关的问题。除了STIR中正在进行的工作外，还有其他机制用于验证呼叫者身份。例如，如[EENA]中所述，验证呼叫者身份信息（以及紧急情况的存在）的一种机制是PSAP回拨用户，如[RFC7090]中所述。
Given the existing work on caller identification, this document focuses on the additional threats that are introduced by the support of IP-based emergency services in nomadic and mobile Devices, in which location may be conveyed to the PSAP within the emergency call. Ideally, a call taker at a PSAP should be able to assess, in real time, the level of trust that can be placed on the information provided within a call. This includes automated location conveyed along with the call and location information communicated by the caller, as well as identity information relating to the caller or the Device initiating the call. Where real-time assessment is not possible, it is important to be able to determine the source of the call in a post-incident investigation, so as to be able to enforce accountability.
鉴于现有的呼叫者识别工作，本文件重点关注在游牧和移动设备中支持基于IP的紧急服务所带来的额外威胁，在这些设备中，位置可以在紧急呼叫中传送到PSAP。理想情况下，PSAP中的呼叫接受者应该能够实时评估对呼叫中提供的信息的信任程度。这包括与呼叫一起传送的自动位置和由呼叫者传送的位置信息，以及与呼叫者或发起呼叫的设备相关的身份信息。在无法进行实时评估的情况下，重要的是能够在事后调查中确定呼叫的来源，以便能够实施问责。
This document defines terminology (including the meaning of "trustworthy location") in Section 1.1, reviews existing work in Section 1.2, describes threat models in Section 2, outlines potential mitigation techniques in Section 3, covers trust assessment in Section 4, and discusses security considerations in Section 5.
本文件在第1.1节中定义了术语（包括“可信位置”的含义），在第1.2节中回顾了现有工作，在第2节中描述了威胁模型，在第3节中概述了潜在的缓解技术，在第4节中介绍了信任评估，并在第5节中讨论了安全注意事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
We use the definitions of "Internet Access Provider (IAP)", "Internet Service Provider (ISP)", and "Voice Service Provider (VSP)" found in "Requirements for Emergency Context Resolution with Internet Technologies" [RFC5012].
我们使用“互联网技术紧急上下文解析要求”[RFC5012]中的“互联网接入提供商（IAP）”、“互联网服务提供商（ISP）”和“语音服务提供商（VSP）”的定义。
[EENA] defines a "hoax call" as follows: "A false or malicious call is when a person deliberately telephones the emergency services and tells them there is an emergency when there is not."
[EENA]对“恶作剧电话”的定义如下：“虚假或恶意电话是指一个人故意打电话给应急服务机构，并在没有紧急情况时告诉他们有紧急情况。”
The definitions of "Device", "Target", and "Location Information Server" (LIS) are taken from "An Architecture for Location and Location Privacy in Internet Applications" [RFC6280], Section 7.
“设备”、“目标”和“位置信息服务器”（LIS）的定义取自“互联网应用中的位置和位置隐私架构”[RFC6280]，第7节。
The term "Device" denotes the physical device, such as a mobile phone, PC, or embedded microcontroller, whose location is tracked as a proxy for the location of a Target.
术语“设备”表示物理设备，例如移动电话、PC或嵌入式微控制器，其位置作为目标位置的代理进行跟踪。
The term "Target" denotes an individual or other entity whose location is sought in the Geopriv architecture [RFC6280]. In many cases, the Target will be the human user of a Device, or it may be an object such as a vehicle or shipping container to which a Device is attached. In some instances, the Target will be the Device itself. The Target is the entity whose privacy the architecture described in [RFC6280] seeks to protect.
术语“目标”表示在Geopriv架构中寻找其位置的个人或其他实体[RFC6280]。在许多情况下，目标将是设备的人类用户，或者它可能是设备连接到的对象，例如车辆或运输容器。在某些情况下，目标将是设备本身。目标是[RFC6280]中描述的体系结构试图保护其隐私的实体。
The term "Location Information Server" denotes an entity responsible for providing Devices within an access network with information about their own locations. A Location Information Server uses knowledge of the access network and its physical topology to generate and distribute location information to Devices.
术语“位置信息服务器”表示负责向接入网络内的设备提供关于其自身位置的信息的实体。位置信息服务器使用接入网络及其物理拓扑的知识来生成位置信息并将其分发给设备。
The term "location determination method" refers to the mechanism used to determine the location of a Target. This may be something employed by a LIS or by the Target itself. It specifically does not refer to the location configuration protocol (LCP) used to deliver location information to either the Target or the Recipient. This term is reused from "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations" [RFC5491].
术语“位置确定方法”指用于确定目标位置的机制。这可能是LIS或目标本身使用的东西。具体而言，它没有提及用于向目标或接收方传递位置信息的位置配置协议（LCP）。该术语从“GEOPRIV存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”[RFC5491]中重新使用。
The term "source" is used to refer to the LIS, node, or Device from which a Recipient (Target or third party) obtains location information.
术语“源”用于指接收者（目标或第三方）从中获取位置信息的LIS、节点或设备。
Additionally, the terms "location-by-value" (LbyV), "location-by-reference" (LbyR), "Location Configuration Protocol", "Location Dereference Protocol", and "Location Uniform Resource Identifier" (URI) are reused from "Requirements for a Location-by-Reference Mechanism" [RFC5808].
此外，术语“按值定位”（LbyV）、“按引用定位”（LbyR）、“位置配置协议”、“位置解引用协议”和“位置统一资源标识符”（URI）从“按引用定位机制的要求”[RFC5808]中重复使用。
"Trustworthy Location" is defined as location information that can be attributed to a trusted source, has been protected against modification in transmit, and has been assessed as trustworthy.
“可信位置”定义为可归因于可信源的位置信息，该位置信息在传输过程中受到保护，不受修改，并被评估为可信。
"Location Trust Assessment" refers to the process by which the reliability of location information can be assessed. This topic is discussed in Section 4.
“位置信任评估”是指评估位置信息可靠性的过程。本主题将在第4节中讨论。
"Identity Spoofing" occurs when the attacker forges or obscures their identity so as to prevent themselves from being identified as the source of the attack. One class of identity spoofing attack involves the forging of call origin identification.
“身份欺骗”是指攻击者伪造或隐藏其身份，以防止自己被识别为攻击源。一类身份欺骗攻击涉及伪造呼叫来源标识。
The following additional terms apply to location spoofing (Section 2.3):
以下附加条款适用于位置欺骗（第2.3节）：
With "Place Shifting", attackers construct a Presence Information Data Format Location Object (PIDF-LO) for a location other than where they are currently located. In some cases, place shifting can be limited in range (e.g., within the coverage area of a particular cell tower).
通过“位置转移”，攻击者为其当前所在位置以外的位置构建状态信息数据格式位置对象（PIDF-LO）。在某些情况下，位置转移可能在范围内受到限制（例如，在特定基站的覆盖区域内）。
"Time Shifting" occurs when the attacker uses or reuses location information that was valid in the past but is no longer valid because the attacker has moved.
当攻击者使用或重用过去有效但由于攻击者移动而不再有效的位置信息时，就会发生“时间偏移”。
"Location Theft" occurs when the attacker captures a Target's location information (possibly including a signature) and presents it as their own. Location theft can occur in a single instance or may be continuous (e.g., where the attacker has gained control over the victim's Device). Location theft may also be combined with time shifting to present someone else's location information after the original Target has moved.
当攻击者捕获目标的位置信息（可能包括签名）并将其显示为自己的信息时，就会发生“位置盗窃”。位置盗窃可能发生在单个实例中，也可能是连续发生的（例如，攻击者控制了受害者的设备）。位置盗窃也可能与时间转移相结合，在原始目标移动后显示其他人的位置信息。
This section describes how location is utilized in the Internet Emergency Services Architecture, as well as the existing work on the problem of hoax calls.
本节介绍了如何在Internet紧急服务体系结构中使用位置，以及有关恶作剧呼叫问题的现有工作。
The Internet architecture for emergency calling is described in "Framework for Emergency Calling Using Internet Multimedia" [RFC6443]. Best practices for utilizing the architecture to make emergency calls are described in "Best Current Practice for Communications Services in Support of Emergency Calling" [RFC6881].
紧急呼叫的互联网体系结构在“使用互联网多媒体的紧急呼叫框架”[RFC6443]中进行了描述。“支持紧急呼叫的通信服务最佳当前实践”[RFC6881]中描述了利用体系结构拨打紧急呼叫的最佳实践。
As noted in "An Architecture for Location and Location Privacy in Internet Applications" [RFC6280], Section 6.3:
如“互联网应用中的位置和位置隐私架构”[RFC6280]第6.3节所述：
there are three critical steps in the placement of an emergency call, each involving location information:
紧急呼叫有三个关键步骤，每个步骤都涉及位置信息：
1. Determine the location of the caller.
1. 确定调用者的位置。
2. Determine the proper Public Safety Answering Point (PSAP) for the caller's location.
2. 为呼叫者的位置确定适当的公共安全应答点（PSAP）。
3. Send a SIP INVITE message, including the caller's location, to the PSAP.
3. 向PSAP发送SIP INVITE消息，包括呼叫者的位置。
The conveyance of location information within the Session Initiation Protocol (SIP) is described in "Location Conveyance for the Session Initiation Protocol" [RFC6442]. Conveyance of location-by-value (LbyV) as well as conveyance of location-by-reference (LbyR) are supported. Section 7 of [RFC6442] ("Security Considerations") discusses privacy, authentication, and integrity concerns relating to conveyed location. This includes discussion of transmission-layer security for confidentiality and integrity protection of SIP, as well as (undeployed) end-to-end security mechanisms for protection of location information (e.g., S/MIME). Regardless of whether transmission-layer security is utilized, location information may be available for inspection by an intermediary that -- if it decides that the location value is unacceptable or insufficiently accurate -- may send an error indication or replace the location, as described in [RFC6442], Section 3.4.
会话启动协议（SIP）内位置信息的传输在“会话启动协议的位置传输”[RFC6442]中描述。支持按值传递位置（LbyV）和按参考传递位置（LbyR）。[RFC6442]第7节（“安全注意事项”）讨论了与传输位置相关的隐私、认证和完整性问题。这包括讨论SIP机密性和完整性保护的传输层安全性，以及保护位置信息（如S/MIME）的（未部署的）端到端安全机制。无论是否使用传输层安全性，位置信息都可供中介机构检查，如果中介机构确定位置值不可接受或不够准确，则可发送错误指示或替换位置，如[RFC6442]第3.4节所述。
Although the infrastructure for location-based routing described in [RFC6443] was developed for use in emergency services, [RFC6442] supports conveyance of location within non-emergency calls as well as emergency calls. Section 1 of "Implications of 'retransmission-allowed' for SIP Location Conveyance" [RFC5606] describes the overall architecture, as well as non-emergency usage scenarios (note: the [LOC-CONVEY] citation in the quote below refers to the document later published as [RFC6442]):
尽管[RFC6443]中描述的基于位置的路由基础设施是为用于紧急服务而开发的，[RFC6442]支持在非紧急呼叫和紧急呼叫中传输位置。“允许重传”对SIP位置传输的影响[RFC5606]第1节描述了总体架构以及非紧急使用场景（注：以下引用中的[LOC-TRANSMITE]引用引用了后来发布为[RFC6442]的文件）：
The Presence Information Data Format for Location Objects (PIDF-LO [RFC4119]) carries both location information (LI) and policy information set by the Rule Maker, as is stipulated in [RFC3693]. The policy carried along with LI allows the Rule Maker to restrict, among other things, the duration for which LI will be retained by recipients and the redistribution of LI by recipients.
位置对象的状态信息数据格式（PIDF-LO[RFC4119]）包含规则制定者设置的位置信息（LI）和策略信息，如[RFC3693]所规定。与LI一起实施的政策允许规则制定者除其他事项外，限制收件人保留LI的期限以及收件人对LI的重新分配。
The Session Initiation Protocol [RFC3261] is one proposed Using Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is specified in [LOC-CONVEY]. The common motivation for providing LI in SIP is to allow location to be considered in routing the SIP message. One example use case would be emergency services, in which the location will be used by dispatchers to direct the response. Another use case might be providing location to be used by services associated with the SIP session; a location associated with a call to a taxi service, for example, might be used to route to a local franchisee of a national service and also to route the taxi to pick up the caller.
会话启动协议[RFC3261]是使用PIDF-LO协议提出的协议。SIP内PIDF-LO的传输在[LOC-TRANSFER]中有规定。在SIP中提供LI的常见动机是允许在路由SIP消息时考虑位置。一个示例用例是紧急服务，调度员将使用该位置来指示响应。另一个用例可能是提供与SIP会话相关联的服务使用的位置；例如，与呼叫出租车服务相关联的位置可用于路由到当地国家服务特许经营商，也可用于路由出租车以接来电者。
Hoax calls have been a problem for emergency services dating back to the time of street corner call boxes. As the European Emergency Number Association (EENA) has noted [EENA]:
恶作剧电话一直是紧急服务的一个问题，可以追溯到街角电话亭的时代。正如欧洲紧急号码协会（EENA）所指出的[EENA]：
False emergency calls divert emergency services away from people who may be in life-threatening situations and who need urgent help. This can mean the difference between life and death for someone in trouble.
虚假的紧急呼叫将紧急服务从那些可能处于危及生命的情况和需要紧急帮助的人身上转移开。这可能意味着有麻烦的人生死攸关。
EENA [EENA] has attempted to define terminology and describe best current practices for dealing with false emergency calls. Reducing the number of hoax calls represents a challenge, since emergency services authorities in most countries are required to answer every call (whenever possible). Where the caller cannot be identified, the ability to prosecute is limited.
EENA[EENA]试图定义术语并描述处理虚假紧急呼叫的最佳当前实践。减少骗局电话的数量是一项挑战，因为大多数国家的应急服务机构都被要求接听每一个电话（只要可能）。如果无法识别呼叫者，起诉的能力是有限的。
A particularly dangerous form of hoax call is "swatting" -- a hoax emergency call that draws a response from law enforcement prepared for a violent confrontation (e.g., a fake hostage situation that results in the dispatching of a "Special Weapons And Tactics" (SWAT) team). In 2008, the Federal Bureau of Investigation (FBI) issued a warning [Swatting] about an increase in the frequency and sophistication of these attacks.
一种特别危险的恶作剧电话形式是“斯瓦特”——一种恶作剧紧急电话，引起执法部门的反应，为暴力对抗做好准备（例如，导致派遣“特殊武器和战术”（SWAT）小组的假人质情况）。2008年，联邦调查局（FBI）就这些袭击的频率和复杂性的增加发出了警告。
Many documented cases of "swatting" (also sometimes referred to as "SWATing") involve not only the faking of an emergency but also falsification or obfuscation of identity [Swatting] [SWATing]. There are a number of techniques by which hoax callers attempt to avoid identification, and in general, the ability to identify the caller appears to influence the incidence of hoax calls.
许多记录在案的“拍打”（有时也称为“拍打”）案件不仅涉及伪造紧急情况，还涉及伪造或混淆身份[拍打][拍打]。恶作剧呼叫者试图避免识别的技术有很多，一般来说，识别呼叫者的能力似乎会影响恶作剧呼叫者的发生率。
Where a Voice Service Provider allows the caller to configure its outbound caller identification without checking it against the authenticated identity, forging caller identification is trivial. Similarly, where an attacker can gain entry to a Private Branch Exchange (PBX), they can then subsequently use that access to launch a denial-of-service attack against the PSAP or make fraudulent emergency calls. Where emergency calls have been allowed from handsets lacking a subscriber identification module (SIM) card, so-called non-service initialized (NSI) handsets, or where ownership of the SIM card cannot be determined, the frequency of hoax calls has often been unacceptably high [TASMANIA] [UK] [SA].
如果语音服务提供商允许呼叫者配置其出站呼叫者标识，而无需对照经过身份验证的标识进行检查，那么伪造呼叫者标识就很简单了。类似地，如果攻击者可以进入专用分支交换机（PBX），他们随后可以使用该访问对PSAP发起拒绝服务攻击或进行欺诈性紧急呼叫。如果允许从没有用户识别模块（SIM）卡的手机、所谓的非服务初始化（NSI）手机拨打紧急呼叫，或者无法确定SIM卡的所有权，则恶作剧呼叫的频率通常高得令人无法接受[TASMANIA][UK][SA]。
However, there are few documented cases of hoax calls that have arisen from conveyance of untrustworthy location information within an emergency call, which is the focus of this document.
然而，由于在紧急呼叫中传输不可信的位置信息而导致的恶作剧呼叫案例很少，这是本文件的重点。
This section reviews existing analyses of the security of emergency services, threats to geographic location privacy, threats relating to spoofing of caller identification, and threats related to modification of location information in transit. In addition, the threat model applying to this work is described.
本节回顾了现有的应急服务安全分析、地理位置隐私的威胁、与欺骗来电者身份相关的威胁以及与修改传输中的位置信息相关的威胁。此外，还描述了应用于这项工作的威胁模型。
"An Architecture for Location and Location Privacy in Internet Applications" [RFC6280] describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services.
“互联网应用程序中的位置和位置隐私架构”[RFC6280]描述了互联网中保护隐私的基于位置的服务架构，重点关注这些服务使用的数据格式和协议的授权、安全和隐私要求。
In Section 5 of [RFC6280] ("An Architecture for Location and Location Privacy in Internet Applications"), mechanisms for ensuring the security of the location distribution chain are discussed; these include mechanisms for hop-by-hop confidentiality and integrity protection as well as end-to-end assurance.
[RFC6280]第5节（“互联网应用中的位置和位置隐私架构”）讨论了确保位置分发链安全的机制；其中包括用于逐跳保密性和完整性保护以及端到端保证的机制。
"Geopriv Requirements" [RFC3693] focuses on the authorization, security, and privacy requirements of location-dependent services, including emergency services. Section 8 of [RFC3693] includes discussion of emergency services authentication (Section 8.3), and issues relating to identity and anonymity (Section 8.4).
“Geopriv要求”[RFC3693]侧重于位置相关服务（包括紧急服务）的授权、安全和隐私要求。[RFC3693]第8节讨论了应急服务认证（第8.3节）以及与身份和匿名性相关的问题（第8.4节）。
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats against geographic location privacy, including protocol threats, threats resulting from the storage of geographic location data, and threats posed by the abuse of information.
“Geopriv协议的威胁分析”[RFC3694]描述了对地理位置隐私的威胁，包括协议威胁、地理位置数据存储造成的威胁以及信息滥用造成的威胁。
"Security Threats and Requirements for Emergency Call Marking and Mapping" [RFC5069] reviews security threats associated with the marking of signaling messages and the process of mapping locations to Universal Resource Identifiers (URIs) that point to PSAPs. RFC 5069 describes attacks on the emergency services system, such as attempting to deny system services to all users in a given area, to gain fraudulent use of services and to divert emergency calls to non-emergency sites. In addition, it describes attacks against individuals, including attempts to prevent an individual from receiving aid, or to gain information about an emergency, as well as attacks on emergency services infrastructure elements, such as mapping discovery and mapping servers.
“紧急呼叫标记和映射的安全威胁和要求”[RFC5069]审查与信令消息标记相关的安全威胁，以及将位置映射到指向PSAP的通用资源标识符（URI）的过程。RFC 5069描述了对紧急服务系统的攻击，例如试图拒绝向给定区域内的所有用户提供系统服务，以获取对服务的欺诈性使用，并将紧急呼叫转移到非紧急站点。此外，它还描述了针对个人的攻击，包括试图阻止个人接受援助或获取有关紧急情况的信息，以及对应急服务基础设施要素（如地图发现和地图服务器）的攻击。
"Secure Telephone Identity Threat Model" [RFC7375] analyzes threats relating to impersonation and obscuring of calling party numbers, reviewing the capabilities available to attackers, and the scenarios in which attacks are launched.
“安全电话身份威胁模型”[RFC7375]分析与模拟和隐藏呼叫方号码有关的威胁，审查攻击者可用的能力，以及发起攻击的场景。
To provide a structured analysis, we distinguish between three adversary models:
为了提供结构化分析，我们区分了三种对手模型：
External adversary model: The end host, e.g., an emergency caller whose location is going to be communicated, is honest, and the adversary may be located between the end host and the location server or between the end host and the PSAP. None of the emergency service infrastructure elements act maliciously.
外部对手模型：终端主机（例如，其位置将要通信的紧急呼叫方）是诚实的，对手可能位于终端主机和位置服务器之间或终端主机和PSAP之间。所有应急服务基础设施要素都没有恶意行为。
Malicious infrastructure adversary model: The emergency call routing elements, such as the Location Information Server (LIS), the Location-to-Service Translation (LoST) infrastructure (which is used for mapping locations to PSAP addresses), or call routing elements, may act maliciously.
恶意基础设施对手模型：紧急呼叫路由元素，如位置信息服务器（LIS）、位置到服务转换（丢失）基础设施（用于将位置映射到PSAP地址）或呼叫路由元素，可能会恶意行事。
Malicious end host adversary model: The end host itself acts maliciously, whether the owner is aware of this or the end host is acting under the control of a third party.
恶意终端主机对手模型：终端主机本身的行为是恶意的，无论其所有者是否意识到这一点，或者终端主机是在第三方的控制下进行的。
Since previous work describes attacks against infrastructure elements (e.g., location servers, call route servers, mapping servers) or the emergency services IP network, as well as threats from attackers attempting to snoop location in transit, this document focuses on the threats arising from end hosts providing false location information within emergency calls (the malicious end host adversary model).
由于之前的工作描述了对基础设施元素（如位置服务器、呼叫路由服务器、映射服务器）或应急服务IP网络的攻击，以及来自试图在传输过程中窥探位置的攻击者的威胁，本文档重点介绍因终端主机在紧急呼叫中提供虚假位置信息而产生的威胁（恶意终端主机对手模型）。
Since the focus is on malicious hosts, we do not cover threats that may arise from attacks on infrastructure that hosts depend on to obtain location. For example, end hosts may obtain location from civilian GPS, which is vulnerable to spoofing [GPSCounter], or from third-party Location Service Providers (LSPs) that may be vulnerable to attack or may not provide location accuracy suitable for emergency purposes.
由于重点是恶意主机，因此我们不涵盖主机获取位置所依赖的基础设施上的攻击可能产生的威胁。例如，终端主机可从民用GPS（易受欺骗[GPSChonter]）或第三方位置服务提供商（LSP）获取位置，后者可能易受攻击或无法提供适合紧急情况的位置准确度。
Also, we do not cover threats arising from inadequate location infrastructure. For example, the LIS or end host could base its location determination on a stale wiremap or an inaccurate access point location database, leading to an inaccurate location estimate. Similarly, a Voice Service Provider (VSP) (and, indirectly, a LIS) could utilize the wrong identity (such as an IP address) for location lookup, thereby providing the end host with misleading location information.
此外，我们不涵盖因位置基础设施不足而产生的威胁。例如，LIS或终端主机可能根据陈旧的wiremap或不准确的接入点位置数据库确定其位置，从而导致位置估计不准确。类似地，语音服务提供商（VSP）（以及间接地，LIS）可以利用错误的身份（例如IP地址）进行位置查找，从而向终端主机提供误导性的位置信息。
Where location is attached to the emergency call by an end host, the end host can fabricate a PIDF-LO and convey it within an emergency call. The following represent examples of location spoofing:
当终端主机将位置连接到紧急呼叫时，终端主机可以制作PIDF-LO并在紧急呼叫中传送。以下是位置欺骗的示例：
Place shifting: Mallory, the adversary, pretends to be at an arbitrary location.
地点转移：对手马洛里假装在任意地点。
Time shifting: Mallory pretends to be at a location where she was a while ago.
时间转移：马洛里假装在她刚才所在的地方。
Location theft: Mallory observes or obtains Alice's location and replays it as her own.
位置盗窃：马洛里观察或获得爱丽丝的位置，并将其作为自己的位置重放。
While this document does not focus on the problems created by determination of location based on spoofed caller identification, the ability to ascertain identity is important, since the threat of punishment reduces hoax calls. As an example, calls from pay phones are subject to greater scrutiny by the call taker.
虽然本文件不关注基于伪造来电者身份确定位置所产生的问题，但确定身份的能力很重要，因为惩罚的威胁减少了恶作剧呼叫。例如，付费电话的通话会受到接听者更严格的审查。
With calls originating on an IP network, at least two forms of identity are relevant, with the distinction created by the split between the IAP and the VSP:
对于源自IP网络的呼叫，至少有两种形式的标识是相关的，IAP和VSP之间的分离产生了区别：
(a) network access identity such as might be determined via authentication (e.g., using the Extensible Authentication Protocol (EAP) [RFC3748]);
(a) 网络访问标识，例如可通过身份验证（例如，使用可扩展身份验证协议（EAP）[RFC3748]）确定的网络访问标识；
(b) caller identity, such as might be determined from authentication of the emergency caller at the VoIP application layer.
(b) 呼叫者身份，例如，可以通过VoIP应用层上紧急呼叫者的身份验证来确定。
If the adversary did not authenticate itself to the VSP, then accountability may depend on verification of the network access identity. However, the network access identity may also not have been authenticated, such as in the case where an open IEEE 802.11 Access Point is used to initiate a hoax emergency call. Although endpoint information such as the IP address or Media Access Control (MAC) address may have been logged, tying this back to the Device owner may be challenging.
如果对手没有向VSP进行身份验证，那么责任可能取决于对网络访问身份的验证。然而，网络接入标识也可能尚未被认证，例如在使用开放的IEEE 802.11接入点来发起骗局紧急呼叫的情况下。尽管端点信息（如IP地址或媒体访问控制（MAC）地址）可能已被记录，但将其与设备所有者联系起来可能是一项挑战。
Unlike the existing telephone system, VoIP emergency calls can provide an identity that need not necessarily be coupled to a business relationship with the IAP, ISP, or VSP. However, due to the time-critical nature of emergency calls, multi-layer authentication is undesirable. Thus, in most cases, only the Device placing the call will be able to be identified. Furthermore, deploying additional credentials for emergency service purposes (such as certificates) increases costs, introduces a significant administrative overhead, and is only useful if widely deployed.
与现有的电话系统不同，VoIP紧急呼叫可以提供不必与IAP、ISP或VSP建立业务关系的身份。然而，由于紧急呼叫的时间紧迫性，多层身份验证是不可取的。因此，在大多数情况下，只能识别发出呼叫的设备。此外，部署用于紧急服务目的的附加凭据（如证书）会增加成本，引入大量管理开销，并且只有在广泛部署时才有用。
The sections that follow present three mechanisms for mitigating the threats presented in Section 2:
以下各节介绍了缓解第2节所述威胁的三种机制：
1. Signed location-by-value (Section 3.1), which provides for authentication and integrity protection of the PIDF-LO. There is only an expired straw-man proposal for this mechanism [Loc-Dependability]; thus, as of the time of this writing this mechanism is not suitable for deployment.
1. 按值签名的位置（第3.1节），提供PIDF-LO的身份验证和完整性保护。对于该机制[Loc可靠性]只有一个过期的草人提案；因此，在撰写本文时，该机制不适合部署。
2. Location-by-reference (Section 3.2), which enables location to be obtained by the PSAP directly from the location server, over a confidential and integrity-protected channel, avoiding modification by the end host or an intermediary. This mechanism is specified in [RFC6753].
2. 参考位置（第3.2节），使PSAP能够通过保密和完整性保护通道直接从位置服务器获取位置，避免终端主机或中介进行修改。[RFC6753]中规定了该机制。
3. Proxy-added location (Section 3.3), which protects against location forgery by the end host. This mechanism is specified in [RFC6442].
3. 代理添加位置（第3.3节），防止终端主机伪造位置。[RFC6442]中规定了该机制。
With location signing, a location server signs the location information before it is sent to the Target. The signed location information is then sent to the Location Recipient, who verifies it.
使用位置签名，位置服务器在将位置信息发送到目标之前对其进行签名。然后将签名的位置信息发送给位置收件人，由其进行验证。
Figure 1 shows the communication model with the Target requesting signed location in step (a); the location server returns it in step (b), and it is then conveyed to the Location Recipient, who verifies it (step (c)). For SIP, the procedures described in "Location Conveyance for the Session Initiation Protocol" [RFC6442] are applicable for location conveyance.
图1显示了与在步骤（a）中请求签名位置的目标的通信模型；位置服务器在步骤（b）中将其返回，然后将其传送给位置接收者，由其验证（步骤（c））。对于SIP，“会话启动协议的位置传输”[RFC6442]中描述的过程适用于位置传输。
+-----------+ +-----------+
| | | Location |
| LIS | | Recipient |
| | | |
+-+-------+-+ +----+------+
^ | --^
| | --
Geopriv |Req. | --
Location |Signed |Signed -- Protocol Conveying
Configuration |Loc. |Loc. -- Location (e.g., SIP)
Protocol |(a) |(b) -- (c)
| v --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
+-----------+ +-----------+
| | | Location |
| LIS | | Recipient |
| | | |
+-+-------+-+ +----+------+
^ | --^
| | --
Geopriv |Req. | --
Location |Signed |Signed -- Protocol Conveying
Configuration |Loc. |Loc. -- Location (e.g., SIP)
Protocol |(a) |(b) -- (c)
| v --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 1: Location Signing
图1：位置标志
A straw-man proposal for location signing is provided in "Digital Signature Methods for Location Dependability" [Loc-Dependability]. Note that since [Loc-Dependability] is no longer under development, location signing cannot be considered deployable at the time of this writing.
“位置可靠性数字签名方法”[Loc可信性]中提供了位置签名的草人方案。请注意，由于[Loc可信性]不再处于开发阶段，因此在撰写本文时，位置签名不能被视为可部署。
In order to limit replay attacks, that proposal calls for the addition of a "validity" element to the PIDF-LO, including a "from" sub-element containing the time that location information was validated by the signer, as well as an "until" sub-element containing the last time that the signature can be considered valid.
为了限制重播攻击，该提案要求在PIDF-LO中添加一个“有效性”元素，包括一个“起始”子元素，其中包含签名人验证位置信息的时间，以及一个“直到”子元素，其中包含签名最后一次被视为有效的时间。
One of the consequences of including an "until" element is that even a stationary Target would need to periodically obtain a fresh PIDF-LO, or incur the additional delay of querying during an emergency call.
包含“直到”元素的后果之一是，即使是固定目标也需要定期获取新的PIDF-LO，或者在紧急呼叫期间产生额外的查询延迟。
Although privacy-preserving procedures may be disabled for emergency calls, by design, PIDF-LO objects limit the information available for real-time attribution. As noted in [RFC5985], Section 6.6:
尽管紧急呼叫可能会禁用隐私保护程序，但根据设计，PIDF-LO对象限制了可用于实时归属的信息。如[RFC5985]第6.6节所述：
The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document.
LIS不得在PIDF-LO中包含任何识别设备的方法，除非其能够验证标识符是否正确，并且规则制定者明确允许包含标识。因此，包含标识的PIDF参数要么被忽略，要么包含未链接的假名[RFC3693]。LIS应为PIDF文档的强制存在“实体”属性生成唯一的、未链接的存在实体URI。
Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used.
不使用可选参数，如“触点”和“设备ID”元素[RFC4479]。
Also, the Device referred to in the PIDF-LO may not necessarily be the same entity conveying the PIDF-LO to the PSAP. As noted in [RFC6442], Section 1:
此外，PIDF-LO中提及的设备不一定是将PIDF-LO传送到PSAP的相同实体。如[RFC6442]第1节所述：
In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a Device controlled by the Target, for example, a mobile phone, but such Devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location.
本文档绝不假设发送包含位置对象的请求的SIP用户代理客户端一定是目标。SIP内传送的目标的位置通常对应于由目标控制的设备的位置，例如移动电话，但是这些设备可以与其所有者分离，并且，在某些情况下，用户代理可能不知道其自身的位置。
Without the ability to tie the Target identity to the identity asserted in the SIP message, it is possible for an attacker to cut and paste a PIDF-LO obtained by a different Device or user into a SIP INVITE and send this to the PSAP. This cut-and-paste attack could succeed even when a PIDF-LO is signed or when [RFC4474] is implemented.
如果无法将目标标识与SIP消息中声明的标识联系起来，攻击者可能会将不同设备或用户获得的PIDF-LO剪切并粘贴到SIP INVITE中，并将其发送到PSAP。即使在签署PIDF-LO或实现[RFC4474]时，这种剪切粘贴攻击也可能成功。
To address location-spoofing attacks, [Loc-Dependability] proposes the addition of an "identity" element that could include a SIP URI (enabling comparison against the identity asserted in the SIP headers) or an X.509v3 certificate. If the Target was authenticated by the LIS, an "authenticated" attribute is added. However, because the inclusion of an "identity" element could enable location tracking, a "hash" element is also proposed that could instead contain a hash of the content of the "identity" element. In practice, such a hash would not be much better for real-time validation than a pseudonym.
为了应对位置欺骗攻击，[Loc可信性]建议添加一个“标识”元素，该元素可能包括SIP URI（允许与SIP头中声明的标识进行比较）或X.509v3证书。如果目标已由LIS验证，则会添加“authenticated”属性。然而，由于包含“identity”元素可以实现位置跟踪，因此还提出了一个“hash”元素，该元素可以包含“identity”元素内容的散列。在实践中，这样的散列对于实时验证来说并不比假名好多少。
Location signing cannot deter attacks in which valid location information is provided. For example, an attacker in control of compromised hosts could launch a denial-of-service attack on the PSAP by initiating a large number of emergency calls, each containing valid signed location information. Since the work required to verify the location signature is considerable, this could overwhelm the PSAP infrastructure.
位置签名无法阻止提供有效位置信息的攻击。例如，控制受损主机的攻击者可以通过发起大量紧急呼叫（每个呼叫都包含有效的签名位置信息）对PSAP发起拒绝服务攻击。由于验证位置签名所需的工作非常繁重，这可能会使PSAP基础设施无法承受。
However, while DDoS attacks are unlikely to be deterred by location signing, accurate location information would limit the subset of compromised hosts that could be used for an attack, as only hosts within the PSAP serving area would be useful in placing emergency calls.
然而，虽然位置签名不太可能阻止DDoS攻击，但准确的位置信息将限制可用于攻击的受损主机子集，因为只有PSAP服务区域内的主机才有助于拨打紧急呼叫。
Location signing is also difficult when the host obtains location via mechanisms such as GPS, unless trusted computing approaches, with tamper-proof GPS modules, can be applied. Otherwise, an end host can pretend to have GPS, and the Recipient will need to rely on its ability to assess the level of trust that should be placed in the end host location claim.
当主机通过GPS等机制获取位置时，位置签名也很困难，除非可以应用具有防篡改GPS模块的可信计算方法。否则，最终主机可以假装拥有GPS，而接收方将需要依靠其评估最终主机位置声明中应放置的信任级别的能力。
Even though location-signing mechanisms have not been standardized, [NENA-i2], Section 4.7 includes operational recommendations relating to location signing:
尽管位置签名机制尚未标准化，[NENA-i2]，但第4.7节包括与位置签名相关的操作建议：
Location configuration and conveyance requirements are described in NENA 08-752[27], but guidance is offered here on what should be considered when designing mechanisms to report location:
NENA 08-752[27]中描述了位置配置和运输要求，但此处提供了设计报告位置的机构时应考虑的指导：
1. The location object should be digitally signed.
1. 应该对位置对象进行数字签名。
2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VPC and ERDB operators should issue certificates to LIS operators.
2. 签名人（LIS操作员）的证书应以VESA为根。为此，VPC和ERDB运营商应向LIS运营商颁发证书。
3. The signature should include a timestamp.
3. 签名应包括时间戳。
4. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence.
4. 在可能的情况下，应该定期刷新Location对象，从而刷新签名（以及时间戳）。
5. Antispoofing mechanisms should be applied to the Location Reporting method.
5. 位置报告方法应采用防喷机制。
(Note: The term "Valid Emergency Services Authority" (VESA) refers to the root certificate authority. "VPC" stands for VoIP Positioning Center, and "ERDB" stands for the Emergency Service Zone Routing Database.)
（注：术语“有效紧急服务机构”（VESA）指根证书机构。“VPC”表示VoIP定位中心，“ERDB”表示紧急服务区路由数据库。）
As noted above, signing of location objects implies the development of a trust hierarchy that would enable a certificate chain provided by the LIS operator to be verified by the PSAP. Rooting the trust hierarchy in the VESA can be accomplished either by having the VESA directly sign the LIS certificates or by the creation of intermediate Certificate Authorities (CAs) certified by the VESA, which will then issue certificates to the LIS. In terms of the workload imposed on the VESA, the latter approach is highly preferable. However, this raises the question of who would operate the intermediate CAs and what the expectations would be.
如上所述，位置对象的签名意味着建立信任层次结构，使LIS操作员提供的证书链能够由PSAP进行验证。可以通过让VESA直接签署LIS证书，或者通过创建由VESA认证的中间证书颁发机构（CA），然后向LIS颁发证书，来实现VESA中信任层次结构的根。就VESA的工作量而言，后一种方法是非常可取的。然而，这就提出了一个问题，即谁将操作中间CAs，以及期望值是什么。
In particular, the question arises as to the requirements for LIS certificate issuance, and how they would compare to requirements for issuance of other certificates such as a Secure Socket Layer/Transport Layer Security (SSL/TLS) web certificate.
特别是，问题在于LIS证书颁发的要求，以及这些要求与其他证书（如安全套接字层/传输层安全（SSL/TLS）web证书）的颁发要求相比如何。
Location-by-reference was developed so that end hosts can avoid having to periodically query the location server for up-to-date location information in a mobile environment. Additionally, if operators do not want to disclose location information to the end host without charging them, location-by-reference provides a reasonable alternative. Also, since location-by-reference enables the PSAP to directly contact the location server, it avoids potential attacks by intermediaries.
开发了按引用定位，这样终端主机就可以避免在移动环境中定期向定位服务器查询最新的位置信息。此外，如果运营商不想在不向终端主机收费的情况下向终端主机披露位置信息，则参考定位提供了一种合理的选择。此外，由于通过引用定位使PSAP能够直接联系定位服务器，因此它避免了中间人的潜在攻击。
As noted in "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location reference can be obtained via HELD [RFC5985]. In addition, "Location Configuration Extensions for Policy Management" [RFC7199] extends location configuration protocols such as HELD to provide hosts with a reference to the rules that apply to a location-by-reference so that the host can view or set these rules.
如“使用启用HTTP的位置传递（HOLD）的位置解引用协议”[RFC6753]中所述，可以通过HOLD[RFC5985]获得位置引用。此外，“用于策略管理的位置配置扩展”[RFC7199]扩展了位置配置协议，如HOLD，以向主机提供对通过引用应用于位置的规则的引用，以便主机可以查看或设置这些规则。
Figure 2 shows the communication model with the Target requesting a location reference in step (a); the location server returns the reference and, potentially, the policy in step (b), and it is then conveyed to the Location Recipient in step (c). The Location Recipient needs to resolve the reference with a request in step (d). Finally, location information is returned to the Location Recipient afterwards. For location conveyance in SIP, the procedures described in [RFC6442] are applicable.
图2显示了与目标在步骤（a）中请求位置参考的通信模型；位置服务器在步骤（b）中返回引用，并可能返回策略，然后在步骤（c）中将其传递给位置接收者。位置接收者需要通过步骤（d）中的请求解析引用。最后，位置信息随后返回给位置接收者。对于SIP中的位置传输，[RFC6442]中描述的程序适用。
+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +<------------->+ Recipient |
| | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+
^ | --^
| | --
Geopriv |Req. |LbyR + --
Location |LbyR |Policy -- Protocol Conveying
Configuration |(a) |(b) -- Location (e.g., SIP)
Protocol | | -- (c)
| V --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +<------------->+ Recipient |
| | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+
^ | --^
| | --
Geopriv |Req. |LbyR + --
Location |LbyR |Policy -- Protocol Conveying
Configuration |(a) |(b) -- Location (e.g., SIP)
Protocol | | -- (c)
| V --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 2: Location-by-Reference
图2：参考位置
Where location-by-reference is provided, the Recipient needs to dereference the LbyR in order to obtain location. The details for the dereferencing operations vary with the type of reference, such as an HTTP, HTTPS, SIP, secure SIP (SIPS), or SIP Presence URI.
如果提供了参考位置，收件人需要取消对LbyR的参考以获得位置。解引用操作的详细信息因引用类型而异，例如HTTP、HTTPS、SIP、安全SIP（SIPS）或SIP存在URI。
For location-by-reference, the location server needs to maintain one or several URIs for each Target, timing out these URIs after a certain amount of time. References need to expire to prevent the Recipient of such a Uniform Resource Locator (URL) from being able to permanently track a host and to offer garbage collection functionality for the location server.
对于按引用定位，定位服务器需要为每个目标维护一个或多个URI，并在一定时间后超时这些URI。引用需要过期，以防止此类统一资源定位器（URL）的收件人能够永久跟踪主机并为位置服务器提供垃圾收集功能。
Off-path adversaries must be prevented from obtaining the Target's location. The reference contains a randomized component that prevents third parties from guessing it. When the Location Recipient fetches up-to-date location information from the location server, it can also be assured that the location information is fresh and not replayed. However, this does not address location theft.
必须防止非路径对手获取目标位置。该引用包含一个随机化组件，可防止第三方猜测它。当位置接收者从位置服务器获取最新的位置信息时，还可以确保位置信息是新的且不会重播。但是，这并不能解决位置盗窃问题。
With respect to the security of the dereference operation, [RFC6753], Section 6 states:
关于解引用操作的安全性，[RFC6753]，第6节规定：
TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted.
TLS必须用于解除对位置URI的引用，除非其他机制提供机密性和完整性，如第3节所述。位置收件人必须使用位置URI中包含的域名，使用[RFC2818]第3.1节中描述的程序验证主机身份。本地策略确定在身份验证失败或无法尝试身份验证时位置收件人的操作。
The authorization by possession model (Section 4.1) further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references.
占有授权模型（第4.1节）在传输位置URI时进一步依赖TLS，以保护URI的保密性。拥有这样一个URI意味着与拥有该URI引用的PIDF-LO文档相同的隐私考虑。
Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] designates the Rule Maker to authorize disclosure of the URI.
位置URI只能披露给授权的位置收件人。GEOPRIV体系结构[RFC6280]指定规则制定者授权披露URI。
Protection of the location URI is necessary, since the policy attached to such a location URI permits anyone who has the URI to view the associated location information. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442].
保护位置URI是必要的，因为附加到此类位置URI的策略允许拥有该URI的任何人查看关联的位置信息。位置传输协议规范（如[RFC6442]）更详细地介绍了安全性的这一方面。
For authorizing access to location-by-reference, two authorization models were developed: "Authorization by Possession" and "Authorization via Access Control Lists". With respect to "Authorization by Possession", [RFC6753], Section 4.1 notes:
为了通过引用授权访问位置，开发了两种授权模型：“通过占有授权”和“通过访问控制列表授权”。关于“占有授权”[RFC6753]，第4.1节注释：
In this model, possession -- or knowledge -- of the location URI is used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]), and the set of entities that it is disclosed to can be limited. The only authentication this would require by the LS is evidence of possession of the URI. The LS could immediately authorize any request that indicates this URI.
在这个模型中，位置URI的拥有权（或知识）用于控制对位置信息的访问。位置URI的构造可以使其难以猜测（参见[RFC5808]的C8），并且可以限制其公开的实体集。LS需要的唯一身份验证是拥有URI的证据。LS可以立即授权指示此URI的任何请求。
Authorization by possession does not require direct interaction with a Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker.
占有授权不需要与规则制定者直接互动；假设规则制定者能够控制位置URI的分布。因此，LIS可以在规则制定者有限的策略输入下运行。
Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers.
有限披露是该授权模型的一个重要方面。位置URI是一个秘密；因此，确保对手无法获取此信息至关重要。TLS[RFC5246]或S/MIME[RFC5751]可能提供的加密保护信息不被窃听。
...
...
Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue to learn new location URIs to retain access to current location information.
使用占有权作为授权的基础意味着，一旦授予，授权就不能轻易撤销。取消位置URI可确保合法用户也受到影响；附加政策的应用在理论上是可行的，但在技术上可能是不可行的。位置URI的过期限制了位置URI的可用时间，要求攻击者继续学习新的位置URI以保留对当前位置信息的访问。
In situations where "Authorization by Possession" is not suitable (such as where location hiding [RFC6444] is required), the "Authorization via Access Control Lists" model may be preferred.
在“通过占有进行授权”不合适的情况下（例如需要位置隐藏[RFC6444]），可以首选“通过访问控制列表进行授权”模式。
Without the introduction of a hierarchy, it would be necessary for the PSAP to obtain credentials, such as certificates or shared symmetric keys, for all the LISs in its coverage area, to enable it to successfully dereference LbyRs. In situations with more than a few LISs per PSAP, this would present operational challenges.
在不引入层次结构的情况下，PSAP有必要为其覆盖区域内的所有LIS获取凭证，如证书或共享对称密钥，以使其能够成功地取消对LBYR的引用。在每个PSAP有多个LIS的情况下，这将带来运营挑战。
A certificate hierarchy providing PSAPs with client certificates chaining to the VESA could be used to enable the LIS to authenticate and authorize PSAPs for dereferencing. Note that unlike PIDF-LO signing (which mitigates modification of PIDF-LOs), this merely provides the PSAP with access to a (potentially unsigned) PIDF-LO, albeit over a protected TLS channel.
可以使用证书层次结构为PSAP提供链接到VESA的客户端证书，以使LIS能够对PSAP进行身份验证和授权，从而取消引用。请注意，与PIDF-LO签名（可减轻对PIDF LOs的修改）不同，这仅为PSAP提供对（可能未签名的）PIDF-LO的访问，尽管是通过受保护的TLS信道。
Another approach would be for the local LIS to upload location information to a location aggregation point who would in turn manage the relationships with the PSAP. This would shift the management burden from the PSAPs to the location aggregation points.
另一种方法是，本地LIS将位置信息上传到位置聚合点，位置聚合点反过来管理与PSAP的关系。这将把管理负担从PSAP转移到位置聚合点。
Instead of relying upon the end host to provide location, is possible for a proxy that has the ability to determine the location of the end point (e.g., based on the end host IP or MAC address) to retrieve and add or override location information. This requires deployment of application-layer entities by ISPs, unlike the two other techniques. The proxies could be used for emergency or non-emergency communications, or both.
代理可以不依赖终端主机提供位置，而能够确定端点位置（例如，基于终端主机IP或MAC地址）以检索、添加或覆盖位置信息。与其他两种技术不同，这需要ISP部署应用层实体。代理可用于紧急或非紧急通信，或两者兼有。
The use of proxy-added location is primarily applicable in scenarios where the end host does not provide location. As noted in [RFC6442], Section 4.1:
使用代理添加位置主要适用于终端主机不提供位置的场景。如[RFC6442]第4.1节所述：
A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. This will quite often lead to confusion within LRs. However, if a SIP intermediary adds location, even if location was not previously present in a SIP request, that SIP intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition and MUST NOT pass on (upstream) the 424 response. A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request.
SIP中介不应向已包含位置的SIP请求添加位置。这通常会导致LRs内部的混乱。然而，如果SIP中介添加了位置，即使该位置以前没有出现在SIP请求中，该SIP中介完全负责解决其收到的关于该位置添加的任何424（错误位置信息）SIP响应的问题，并且不得传递（上游）424响应。添加locationValue的SIP中介必须将新locationValue定位为SIP请求的Geolocation标头字段中的最后一个locationValue。
...
...
A SIP intermediary MAY add a Geolocation header field if one is not present -- for example, when a user agent does not support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or any of a number of other use cases (see Section 3).
如果不存在地理位置头字段，SIP中介可以添加一个地理位置头字段——例如，当用户代理不支持地理位置机制，但其出站代理支持并知道目标的位置，或者其他许多用例中的任何一个时（参见第3节）。
As noted in [RFC6442], Section 3.3:
如[RFC6442]第3.3节所述：
This document takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by an intermediary entity. That entity becomes completely responsible for all location within that SIP request (more on this in Section 4).
本文档采用“你打破了它，你买了它”的方法来处理中介实体放入SIP请求中的第二个位置。该实体将完全负责该SIP请求中的所有位置（更多信息，请参见第4节）。
While it is possible for the proxy to override location included by the end host, [RFC6442], Section 3.4 notes the operational limitations:
虽然代理可以覆盖终端主机[RFC6442]包含的位置，但第3.4节指出了操作限制：
Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another.
Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another.translate error, please retry
The disadvantage of this approach is the need to deploy application-layer entities, such as SIP proxies, at IAPs or associated with IAPs. This requires that a standardized VoIP profile be deployed at every end Device and at every IAP. This might impose interoperability challenges.
这种方法的缺点是需要在IAP上部署应用层实体，如SIP代理或与IAP相关联的实体。这要求在每个终端设备和每个IAP部署标准化的VoIP配置文件。这可能会带来互操作性挑战。
Additionally, the IAP needs to take responsibility for emergency calls, even for customers with whom they have no direct or indirect relationship. To provide identity information about the emergency caller from the VSP, it would be necessary to let the IAP and the VSP interact for authentication (see, for example, "Diameter Session Initiation Protocol (SIP) Application" [RFC4740]). This interaction along the Authentication, Authorization, and Accounting infrastructure is often based on business relationships between the involved entities. An arbitrary IAP and VSP are unlikely to have a business relationship. If the interaction between the IAP and the VSP fails due to the lack of a business relationship, then typically a fall-back would be provided where no emergency caller identity information is made available to the PSAP and the emergency call still has to be completed.
此外，IAP需要负责紧急呼叫，即使是与他们没有直接或间接关系的客户。为了从VSP提供关于紧急呼叫方的身份信息，有必要让IAP和VSP进行交互以进行身份验证（例如，请参阅“Diameter会话发起协议（SIP）应用程序”[RFC4740]）。身份验证、授权和记帐基础架构中的这种交互通常基于相关实体之间的业务关系。武断的IAP和VSP不太可能有业务关系。如果IAP和VSP之间的交互由于缺乏业务关系而失败，则通常会在PSAP无法获得紧急呼叫者身份信息且紧急呼叫仍需完成的情况下提供回退。
The ability to assess the level of trustworthiness of conveyed location information is important, since this makes it possible to understand how much value should be placed on location information as part of the decision-making process. As an example, if automated location information is understood to be highly suspect or is absent, a call taker can put more effort into verifying the authenticity of the call and obtaining location information from the caller.
评估所传达位置信息的可信度水平的能力很重要，因为这使我们能够了解作为决策过程一部分的位置信息的价值。例如，如果自动位置信息被理解为高度可疑或不存在，则呼叫接受者可以投入更多精力来验证呼叫的真实性并从呼叫者处获取位置信息。
Location trust assessment has value, regardless of whether the location itself is authenticated (e.g., signed location) or is obtained directly from the location server (e.g., location-by-reference) over security transport, since these mechanisms do not provide assurance of the validity or provenance of location data.
位置信任评估具有价值，无论位置本身是否经过身份验证（例如，签名位置）或通过安全传输直接从位置服务器（例如，通过引用位置）获得，因为这些机制不保证位置数据的有效性或来源。
To prevent location-theft attacks, the "entity" element of the PIDF-LO is of limited value if an unlinked pseudonym is provided in this field. However, if the LIS authenticates the Target, then the linkage between the pseudonym and the Target identity can be recovered in a post-incident investigation.
为防止位置盗窃攻击，如果在此字段中提供未链接的笔名，则PIDF-LO的“实体”元素的价值有限。但是，如果LIS认证了目标，则可以在事后调查中恢复笔名和目标身份之间的联系。
As noted in [Loc-Dependability], if the location object was signed, the Location Recipient has additional information on which to base their trust assessment, such as the validity of the signature, the identity of the Target, the identity of the LIS, whether the LIS authenticated the Target, and the identifier included in the "entity" field.
如[Loc可信性]中所述，如果位置对象已签名，则位置接收人有其他信息作为其信任评估的基础，例如签名的有效性、目标的身份、LIS的身份、LIS是否验证了目标以及“实体”字段中包含的标识符。
Caller accountability is also an important aspect of trust assessment. Can the individual purchasing the Device or activating service be identified, or did the call originate from a non-service initialized (NSI) Device whose owner cannot be determined? Prior to the call, was the caller authenticated at the network or application layer? In the event of a hoax call, can audit logs be made available to an investigator, or can information relating to the owner of an unlinked pseudonym be provided, enabling investigators to unravel the chain of events that led to the attack?
呼叫方责任也是信任评估的一个重要方面。是否可以识别购买设备或激活服务的个人，或者呼叫是否来自无法确定所有者的非服务初始化（NSI）设备？在调用之前，调用方是否在网络或应用程序层进行了身份验证？如果发生恶作剧电话，是否可以向调查人员提供审计日志，或者是否可以提供与未链接笔名所有者相关的信息，从而使调查人员能够解开导致攻击的事件链？
In practice, the source of the location data is important for location trust assessment. For example, location provided by a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g., United States Phase II E-911 location accuracy) may be considered more reliable than location information provided by a third-party Location Service Provider (LSP) that disclaims use of location information for emergency purposes.
在实践中，位置数据的来源对于位置信任评估非常重要。例如，由位置信息服务器（LIS）提供的位置，其管理员具有满足紧急位置准确度要求的既定历史（例如，美国第二阶段e-911位置准确度），可能被认为比第三方位置服务提供商（LSP）提供的位置信息更可靠拒绝将位置信息用于紧急用途。
However, even where an LSP does not attempt to meet the accuracy requirements for emergency location, it still may be able to provide information useful in assessing how reliable location information is likely to be. For example, was location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? If based on cell tower or AP location data, was the information obtained from an authoritative source (e.g., the tower or AP owner), and when was the last time that the location of the tower or access point was verified?
然而，即使LSP不试图满足紧急位置的精度要求，它仍然能够提供有用的信息，用于评估位置信息的可靠性。例如，位置是根据最近的基站或802.11接入点（AP）确定的，还是使用了三角测量方法？如果基于基站塔或AP位置数据，信息是否从权威来源（例如，基站塔或AP所有者）获得，以及最后一次验证基站塔或接入点位置是什么时候？
For real-time validation, information in the signaling and media packets can be cross-checked against location information. For example, it may be possible to determine the city, state, country, or continent associated with the IP address included within SIP Via or Contact header fields, or the media source address, and compare this against the location information reported by the caller or conveyed in the PIDF-LO. However, in some situations, only entities close to the caller may be able to verify the correctness of location information.
对于实时验证，可以对照位置信息交叉检查信令和媒体分组中的信息。例如，可以通过或联系人报头字段确定与SIP中包括的IP地址相关联的城市、州、国家或大陆，或媒体源地址，并将其与呼叫者报告的或在PIDF-LO中传送的位置信息进行比较。然而，在某些情况下，只有接近调用者的实体才能验证位置信息的正确性。
Real-time validation of the timestamp contained within PIDF-LO objects (reflecting the time at which the location was determined) is also challenging. To address time-shifting attacks, the "timestamp" element of the PIDF-LO, defined in [RFC3863], can be examined and compared against timestamps included within the enclosing SIP message, to determine whether the location data is sufficiently fresh. However, the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. For example, the Recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it is possible to reset the LIS clock manually without detection. Even if the timestamp was valid at the time location was determined, a time period may elapse between when the PIDF-LO was provided and when it is conveyed to the Recipient. Periodically refreshing location information to renew the timestamp even though the location information itself is unchanged puts additional load on LISs. As a result, Recipients need to validate the timestamp in order to determine whether it is credible.
实时验证PIDF-LO对象中包含的时间戳（反映确定位置的时间）也是一项挑战。为了应对时移攻击，可以检查[RFC3863]中定义的PIDF-LO的“时间戳”元素，并将其与封装的SIP消息中包含的时间戳进行比较，以确定位置数据是否足够新鲜。然而，时间戳仅表示LIS的断言，该断言可能可信，也可能不可信。例如，签名的PIDF-LO的接收者可能不知道LIS是否支持时间同步，或者是否可以在没有检测的情况下手动重置LIS时钟。即使时间戳在确定位置时有效，也可能在提供PIDF-LO和将其传送给接收者之间经过一段时间。定期刷新位置信息以更新时间戳，即使位置信息本身保持不变，也会给LISs带来额外的负载。因此，收件人需要验证时间戳以确定其是否可信。
While this document focuses on the discussion of real-time determination of suspicious emergency calls, the use of audit logs may help in enforcing accountability among emergency callers. For example, in the event of a hoax call, information relating to the owner of the unlinked pseudonym could be provided to investigators, enabling them to unravel the chain of events that led to the attack. However, while auditability is an important deterrent, it is likely to be of most benefit in situations where attacks on the emergency services system are likely to be relatively infrequent, since the resources required to pursue an investigation are likely to be considerable. However, although real-time validation based on PIDF-LO elements is challenging, where LIS audit logs are available (such as where a law enforcement agency can present a subpoena), linking of a pseudonym to the Device obtaining location can be accomplished during an investigation.
虽然本文件侧重于讨论实时确定可疑紧急呼叫，但使用审计日志可能有助于加强紧急呼叫人之间的责任。例如，如果发生骗局电话，可以向调查人员提供与未链接笔名所有者有关的信息，使他们能够解开导致攻击的事件链。然而，尽管可审计性是一种重要的威慑力量，但在对应急服务系统的攻击可能相对较少的情况下，它可能最为有利，因为进行调查所需的资源可能相当可观。然而，尽管基于PIDF-LO元素的实时验证具有挑战性，但在LIS审计日志可用的情况下（例如执法机构可以出示传票的情况下），可以在调查期间完成将笔名与设备获取位置的链接。
Where attacks are frequent and continuous, automated mechanisms are required. For example, it might be valuable to develop mechanisms to exchange audit trail information in a standardized format between ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish potentially fraudulent emergency calls from real emergencies. While a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) may be applied to suspicious calls to lower the risk from bot-nets, this is quite controversial for emergency services, due to the risk of delaying or rejecting valid calls.
如果攻击频繁且持续，则需要自动机制。例如，制定机制，在ISP和PSAP/VSPs以及PSAP之间以标准化格式交换审计跟踪信息，或者开发启发式方法，以区分潜在的欺诈性紧急呼叫和真实的紧急呼叫，这可能很有价值。虽然完全自动化的公共图灵测试（CAPTCHA）可用于区分计算机和人，以降低来自机器人网络的风险，但由于延迟或拒绝有效呼叫的风险，这对于紧急服务来说是相当有争议的。
Although it is important to ensure that location information cannot be faked, the mitigation techniques presented in this document are not universally applicable. For example, there will be many GPS-enabled Devices that will find it difficult to utilize any of the solutions described in Section 3. It is also unlikely that users will be willing to upload their location information for "verification" to a nearby location server located in the access network.
尽管确保位置信息不被伪造很重要，但本文件中介绍的缓解技术并不普遍适用。例如，将有许多启用GPS的设备难以使用第3节中描述的任何解决方案。用户也不太可能愿意将其位置信息上载到位于接入网络中的附近位置服务器进行“验证”。
This document focuses on threats that arise from conveyance of misleading location information, rather than caller identification or authentication and integrity protection of the messages in which location is conveyed. Nevertheless, these aspects are important. In some countries, regulators may not require the authenticated identity of the emergency caller (e.g., emergency calls placed from Public Switched Telephone Network (PSTN) pay phones or SIM-less cell phones). Furthermore, if identities can easily be crafted (as is the case with many VoIP offerings today), then the value of emergency caller authentication itself might be limited. As a result, attackers can forge emergency calls with a lower risk of being held accountable, which may encourage hoax calls.
本文档重点关注因传递误导性位置信息而产生的威胁，而不是呼叫者识别或身份验证以及传递位置的消息的完整性保护。然而，这些方面是重要的。在某些国家，监管机构可能不要求紧急呼叫者的身份验证（例如，从公共交换电话网（PSTN）付费电话或无SIM卡手机拨打的紧急呼叫者）。此外，如果身份可以很容易地构建（就像今天的许多VoIP产品一样），那么紧急呼叫者身份验证本身的价值可能会受到限制。因此，攻击者可以伪造紧急呼叫，从而降低被追究责任的风险，这可能会鼓励恶作剧呼叫。
In order to provide authentication and integrity protection for the Session Initiation Protocol (SIP) messages conveying location, several security approaches are available. It is possible to ensure that modification of the identity and location in transit can be detected by the Location Recipient (e.g., the PSAP), using cryptographic mechanisms, as described in "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474]. However, compatibility with Session Border Controllers (SBCs) that modify integrity-protected headers has proven to be an issue in practice, and as a result, a revision of [RFC4474] is in progress [SIP-Identity]. In the absence of an end-to-end solution, SIP over Transport Layer Security (TLS) can be used to provide message authentication and integrity protection hop by hop.
为了为传输位置的会话发起协议（SIP）消息提供身份验证和完整性保护，有几种安全方法可用。可以确保位置接收者（例如，PSAP）可以使用加密机制检测到对传输中的身份和位置的修改，如“会话发起协议（SIP）中认证身份管理的增强”[RFC4474]中所述。然而，与修改完整性保护头的会话边界控制器（SBC）的兼容性在实践中被证明是一个问题，因此，[RFC4474]的修订正在进行[SIP Identity]。在缺乏端到端解决方案的情况下，可以使用SIP over Transport Layer Security（TLS）逐跳提供消息身份验证和完整性保护。
PSAPs remain vulnerable to distributed denial-of-service attacks, even where the mitigation techniques described in this document are utilized. Placing a large number of emergency calls that appear to come from different locations is an example of an attack that is difficult to carry out within the legacy system but is easier to imagine within IP-based emergency services. Also, in the current system, it would be very difficult for an attacker from one country to attack the emergency services infrastructure located in another country, but this attack is possible within IP-based emergency services.
PSAP仍然容易受到分布式拒绝服务攻击，即使使用了本文档中描述的缓解技术。放置大量似乎来自不同位置的紧急呼叫是一个很难在传统系统中执行但在基于IP的紧急服务中更容易想象的攻击示例。此外，在当前系统中，来自一个国家的攻击者很难攻击位于另一个国家的紧急服务基础设施，但这种攻击在基于IP的紧急服务中是可能的。
While manually mounting the attacks described in Section 2 is non-trivial, the attacks described in this document can be automated. While manually carrying out a location theft would require that the attacker be in proximity to the location being spoofed, or to collude with another end host, an attacker able to run code on an end host can obtain its location and cause an emergency call to be made. While manually carrying out a time-shifting attack would require that the attacker visit the location and submit it before the location information is considered stale, while traveling rapidly away from that location to avoid apprehension, these limitations would not apply to an attacker able to run code on the end host. While obtaining a PIDF-LO from a spoofed IP address requires that the attacker be on the path between the HELD requester and the LIS, if the attacker is able to run code requesting the PIDF-LO, retrieve it from the LIS, and then make an emergency call using it, this attack becomes much easier. To mitigate the risk of automated attacks, service providers can limit the ability of untrusted code (such as WebRTC applications written in JavaScript) to make emergency calls.
虽然手动装载第2节中描述的攻击并非微不足道，但本文档中描述的攻击可以自动执行。虽然手动执行位置盗窃需要攻击者靠近被欺骗的位置，或者与另一个终端主机勾结，但能够在终端主机上运行代码的攻击者可以获取其位置并发出紧急呼叫。虽然手动执行时移攻击需要攻击者在位置信息被视为过时之前访问该位置并提交该位置，同时快速离开该位置以避免担心，但这些限制不适用于能够在最终主机上运行代码的攻击者。虽然从伪造的IP地址获取PIDF-LO需要攻击者位于被扣留的请求者和LIS之间的路径上，但如果攻击者能够运行请求PIDF-LO的代码，从LIS检索PIDF-LO，然后使用它进行紧急呼叫，则此攻击会变得更容易。为了降低自动攻击的风险，服务提供商可以限制不受信任的代码（如用JavaScript编写的WebRTC应用程序）发出紧急呼叫的能力。
Emergency services have three finite resources subject to denial-of-service attacks: the network and server infrastructure; call takers and dispatchers; and the first responders, such as firefighters and police officers. Protecting the network infrastructure is similar to protecting other high-value service providers, except that location information may be used to filter call setup requests, to weed out requests that are out of area. Even for large cities, PSAPs may only have a handful of call takers on duty. So, even if automated techniques are utilized to evaluate the trustworthiness of conveyed location and call takers can, by questioning the caller, eliminate many hoax calls, PSAPs can be overwhelmed even by a small-scale attack. Finally, first-responder resources are scarce, particularly during mass-casualty events.
紧急服务有三个有限的资源受到拒绝服务攻击：网络和服务器基础设施；电话接线员和调度员；以及第一反应者，如消防员和警察。保护网络基础设施与保护其他高价值服务提供商类似，不同之处在于位置信息可用于过滤呼叫设置请求，以清除区域外的请求。即使在大城市，PSAP也可能只有少数接听电话的人值班。因此，即使使用自动化技术来评估所传送位置的可信度，并且呼叫接受者可以通过询问呼叫者来消除许多骗局呼叫，PSAP也可能被小规模的攻击所淹没。最后，急救人员资源匮乏，特别是在大规模伤亡事件期间。
The emergency calling architecture described in [RFC6443] utilizes the PIDF-LO format defined in [RFC4119]. As described in the location privacy architecture [RFC6280], privacy rules that may include policy instructions are conveyed along with the location object.
[RFC6443]中描述的紧急呼叫体系结构使用[RFC4119]中定义的PIDF-LO格式。如位置隐私体系结构[RFC6280]中所述，可能包括策略指令的隐私规则随位置对象一起传送。
The intent of the location privacy architecture was to provide strong privacy protections, as noted in [RFC6280], Section 1.1:
如[RFC6280]第1.1节所述，位置隐私体系结构旨在提供强大的隐私保护
A central feature of the Geopriv architecture is that location information is always bound to privacy rules to ensure that entities that receive location information are informed of how they may use it. These rules can convey simple directives ("do not share my location with others"), or more robust preferences ("allow my spouse to know my exact location all of the time, but only allow my boss to know it during work hours")... The binding of privacy rules to location information can convey users' desire for and expectations of privacy, which in turn helps to bolster social and legal systems' protection of those expectations.
Geopriv体系结构的一个中心特征是位置信息始终与隐私规则相绑定，以确保接收位置信息的实体了解如何使用位置信息。这些规则可以传达简单的指令（“不要与他人分享我的位置”），或更强烈的偏好（“允许我的配偶随时知道我的确切位置，但只允许我的老板在工作时间知道它”）。。。将隐私规则与位置信息绑定可以传达用户对隐私的渴望和期望，这反过来有助于加强社会和法律系统对这些期望的保护。
However, in practice this architecture has limitations that apply within emergency and non-emergency situations. As noted in Section 1.2.2, concerns about hoax calls have led to restrictions on anonymous emergency calls. Caller identification (potentially asserted in SIP via P-Asserted-Identity and SIP Identity) may be used during emergency calls. As a result, in many cases location information transmitted within SIP messages can be linked to caller identity. For example, in the case of a signed LbyV, there are privacy concerns arising from linking the location object to identifiers to prevent replay attacks, as described in Section 3.1.
然而，在实践中，这种体系结构具有适用于紧急和非紧急情况的局限性。如第1.2.2节所述，对恶作剧电话的担忧导致对匿名紧急电话的限制。在紧急呼叫期间，可以使用呼叫者标识（可能通过P-asserted-Identity和SIP-Identity在SIP中断言）。因此，在许多情况下，SIP消息中传输的位置信息可以链接到呼叫者身份。例如，在签名LbyV的情况下，如第3.1节所述，将位置对象链接到标识符以防止重播攻击会引起隐私问题。
The ability to observe location information during emergency calls may also represent a privacy risk. As a result, [RFC6443] requires transmission-layer security for SIP messages, as well as interactions with the location server. However, even where transmission-layer security is used, privacy rules associated with location information may not apply.
在紧急呼叫期间观察位置信息的能力也可能存在隐私风险。因此，[RFC6443]需要SIP消息的传输层安全性，以及与位置服务器的交互。然而，即使在使用传输层安全性的情况下，与位置信息相关联的隐私规则也可能不适用。
In many jurisdictions, an individual requesting emergency assistance is assumed to be granting permission to the PSAP, call taker, and first responders to obtain their location in order to accelerate dispatch. As a result, privacy policies associated with location are implicitly waived when an emergency call is initiated. In addition, when location information is included within SIP messages in either emergency or non-emergency uses, SIP entities receiving the SIP message are implicitly assumed to be authorized Location Recipients, as noted in [RFC5606], Section 3.2:
在许多司法管辖区，假设请求紧急援助的个人向PSAP、呼叫接受者和第一响应者授予获得其位置的许可，以加快派遣。因此，当启动紧急呼叫时，与位置相关的隐私策略被隐式放弃。此外，当在紧急或非紧急情况下SIP消息中包含位置信息时，接收SIP消息的SIP实体被隐含地假定为授权位置接收者，如[RFC5606]第3.2节所述：
Consensus has emerged that any SIP entity that receives a SIP message containing LI through the operation of SIP's normal routing procedures or as a result of location-based routing should be considered an authorized recipient of that LI. Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has <retransmission-allowed> set to "no"; this
已经达成共识，通过SIP的正常路由程序的操作或由于基于位置的路由而接收包含LI的SIP消息的任何SIP实体都应被视为该LI的授权接收者。由于这一假设，一个SIP元素可以将LI传递给另一个，即使它包含的LO已<retransmission allowed>设置为“no”；这
sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if <retransmission-allowed> is set to "no", as it is the passing to third parties that <retransmission-allowed> is meant to control.
将SIP消息传递视为向授权收件人传递的一部分，而不是重传。如果<retransmission allowed>设置为“no”，则SIP实体仍被禁止在正常路由之外将这些消息传递给外部实体，因为<retransmission allowed>的目的是控制传递给第三方。
Where LbyR is utilized rather than LbyV, it is possible to apply more restrictive authorization policies, limiting access to intermediaries and snoopers. However, this is not possible if the "authorization by possession" model is used.
如果使用LbyR而不是LbyV，则可以应用更严格的授权策略，从而限制对中介和窥探者的访问。然而，如果使用“占有授权”模式，这是不可能的。
[EENA] EENA, "False Emergency Calls", EENA Operations Document, Version 1.1, May 2011, <http://www.eena.org/ressource/ static/files/2012_05_04-3.1.2.fc_v1.1.pdf>.
[EENA]EENA，“虚假紧急呼叫”，EENA运营文件，版本1.1，2011年5月<http://www.eena.org/ressource/ static/files/2012\u 05\u 04-3.1.2.fc\u v1.1.pdf>。
[GPSCounter] Warner, J. and R. Johnston, "GPS Spoofing Countermeasures", Los Alamos research paper LAUR-03-6163, December 2003.
华纳，J.和R.约翰斯顿，“全球定位系统欺骗对策”，洛斯阿拉莫斯研究论文LAUR-03-61632003年12月。
[Loc-Dependability] Thomson, M. and J. Winterbottom, "Digital Signature Methods for Location Dependability", Work in Progress, draft-thomson-geopriv-location-dependability-07, March 2011.
[Loc可信性]Thomson，M.和J.Winterbottom，“位置可信性的数字签名方法”，正在进行的工作，草稿-Thomson-geopriv-Location-Reliability-072011年3月。
[NENA-i2] NENA 08-001, "NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)", Version 2, August 2010.
[NENA-i2]NENA 08-001，“增强9-1-1服务（i2）的NENA临时VoIP架构”，第2版，2010年8月。
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004, <http://www.rfc-editor.org/info/rfc3693>.
[RFC3693]Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月<http://www.rfc-editor.org/info/rfc3693>.
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004, <http://www.rfc-editor.org/info/rfc3694>.
[RFC3694]Danley，M.，Mulligan，D.，Morris，J.，和J.Peterson，“Geopriv协议的威胁分析”，RFC 36942004年2月<http://www.rfc-editor.org/info/rfc3694>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "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，Ed.，“可扩展身份验证协议（EAP）”，RFC 37482004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004, <http://www.rfc-editor.org/info/rfc3863>.
[RFC3863]Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月<http://www.rfc-editor.org/info/rfc3863>.
[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>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月<http://www.rfc-editor.org/info/rfc4474>.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006, <http://www.rfc-editor.org/info/rfc4479>.
[RFC4479]Rosenberg，J.，“存在的数据模型”，RFC 4479，2006年7月<http://www.rfc-editor.org/info/rfc4479>.
[RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006, <http://www.rfc-editor.org/info/rfc4740>.
[RFC4740]Garcia Martin，M.，Ed.，Belinchon，M.，Pallares Lopez，M.，Canales Valenzuela，C.，和K.Tammi，“Diameter会话启动协议（SIP）应用”，RFC 47402006年11月<http://www.rfc-editor.org/info/rfc4740>.
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008, <http://www.rfc-editor.org/info/rfc5012>.
[RFC5012]Schulzrinne，H.和R.Marshall，Ed.“使用互联网技术解决紧急情况的要求”，RFC 5012，2008年1月<http://www.rfc-editor.org/info/rfc5012>.
[RFC5069] Taylor, T., Ed., 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.，Ed.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年1月<http://www.rfc-editor.org/info/rfc5069>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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>.
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009, <http://www.rfc-editor.org/info/rfc5606>.
[RFC5606]Peterson，J.，Hardie，T.和J.Morris，“SIP位置传输的‘允许重传’影响”，RFC 5606，2009年8月<http://www.rfc-editor.org/info/rfc5606>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月<http://www.rfc-editor.org/info/rfc5751>.
[RFC5808] Marshall, R., Ed., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010, <http://www.rfc-editor.org/info/rfc5808>.
[RFC5808]Marshall，R.，Ed.“通过参考机制定位的要求”，RFC 5808，2010年5月<http://www.rfc-editor.org/info/rfc5808>.
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010, <http://www.rfc-editor.org/info/rfc5985>.
[RFC5985]Barnes，M.，Ed.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月<http://www.rfc-editor.org/info/rfc5985>.
[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>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011, <http://www.rfc-editor.org/info/rfc6442>.
[RFC6442]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传输”，RFC 64422011年12月<http://www.rfc-editor.org/info/rfc6442>.
[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>.
[RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. Thomson, "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)", RFC 6753, October 2012, <http://www.rfc-editor.org/info/rfc6753>.
[RFC6753]Winterbottom，J.，Tschofenig，H.，Schulzrinne，H.，和M.Thomson，“使用支持HTTP的位置传递（HOLD）的位置解引用协议”，RFC 67532012年10月<http://www.rfc-editor.org/info/rfc6753>.
[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>.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. Patel, "Public Safety Answering Point (PSAP) Callback", RFC 7090, April 2014, <http://www.rfc-editor.org/info/rfc7090>.
[RFC7090]Schulzrinne，H.，Tschofenig，H.，Holmberg，C.，和M.Patel，“公共安全应答点（PSAP）回调”，RFC 70902014年4月<http://www.rfc-editor.org/info/rfc7090>.
[RFC7199] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", RFC 7199, April 2014, <http://www.rfc-editor.org/info/rfc7199>.
[RFC7199]Barnes，R.，Thomson，M.，Winterbottom，J.，和H.Tschofenig，“策略管理的位置配置扩展”，RFC 7199，2014年4月<http://www.rfc-editor.org/info/rfc7199>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, September 2014, <http://www.rfc-editor.org/info/rfc7340>.
[RFC7340]Peterson，J.，Schulzrinne，H.和H.Tschofenig，“安全电话身份问题声明和要求”，RFC 73402014年9月<http://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, October 2014, <http://www.rfc-editor.org/info/rfc7375>.
[RFC7375]Peterson，J.，“安全电话身份威胁模型”，RFC 7375，2014年10月<http://www.rfc-editor.org/info/rfc7375>.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax calls", Arab News, April 5, 2010, <http://www.arabnews.com/node/341463>.
[SA]“沙特阿拉伯——欺诈电话激增的罪魁祸首是非法销售模拟人生”，《阿拉伯新闻》，2010年4月5日<http://www.arabnews.com/node/341463>.
[SIP-Identity] Peterson, J., Jennings, C. and E. Rescorla, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-02, October 2014.
[SIP Identity]Peterson，J.，Jennings，C.和E.Rescorla，“会话启动协议（SIP）中的身份验证管理”，正在进行的工作，草案-ietf-stir-rfc4474bis-02，2014年10月。
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working Group", October 2013, <http://datatracker.ietf.org/wg/stir/charter/>.
[STIR]IETF，“重新访问安全电话身份（STIR）工作组”，2013年10月<http://datatracker.ietf.org/wg/stir/charter/>.
[SWATing] "SWATing 911 Calls", Dispatch Magazine On-Line, April 6, 2013, <http://www.911dispatch.com/ swating-911-calls/>.
[拍打]“拍打911电话”，《在线快讯》杂志，2013年4月6日<http://www.911dispatch.com/ Swatting-911-calls/>。
[Swatting] "Don't Make the Call: The New Phenomenon of 'Swatting'", Federal Bureau of Investigation, February 4, 2008, <http://www.fbi.gov/news/stories/2008/february/ swatting020408>.
[拍打]“不要打电话：拍打的新现象”，联邦调查局，2008年2月4日<http://www.fbi.gov/news/stories/2008/february/ 拍打020408>。
[TASMANIA] "Emergency services seek SIM-less calls block", ABC News Online, August 18, 2006, <http://www.abc.net.au/elections/ tas/2006/news/stories/1717956.htm?elections/tas/2006/>.
[塔斯马尼亚]“紧急服务寻求无SIM卡呼叫阻止”，美国广播公司在线新闻，2006年8月18日<http://www.abc.net.au/elections/ tas/2006/news/stories/1717956.htm？选举/tas/2006/>。
[UK] "Rapper makes thousands of prank 999 emergency calls to UK police", Digital Journal, June 24, 2010, <http://www.digitaljournal.com/article/293796?tp=1>.
[英国]“说唱歌手向英国警方拨打数千个恶作剧999紧急电话”，《数字杂志》，2010年6月24日<http://www.digitaljournal.com/article/293796?tp=1>.
Acknowledgments
致谢
We would like to thank the members of the IETF ECRIT working group, including Marc Linsner and Brian Rosen, for their input at IETF 85 that helped get this document pointed in the right direction. We would also like to thank members of the IETF GEOPRIV working group, including Richard Barnes, Matt Lepinski, Andrew Newton, Murugaraj Shanmugam, and Martin Thomson for their feedback on previous versions of this document. Alissa Cooper, Adrian Farrel, Pete Resnick, Meral Shirazipour, and Bert Wijnen provided helpful review comments during the IETF last call.
我们要感谢IETF ECRIT工作组的成员，包括Marc Linsner和Brian Rosen，感谢他们在IETF 85上的投入，帮助本文件朝着正确的方向发展。我们还要感谢IETF GEOPRIV工作组的成员，包括Richard Barnes、Matt Lepinski、Andrew Newton、Murugaraj Shanmugam和Martin Thomson，感谢他们对本文件先前版本的反馈。Alissa Cooper、Adrian Farrel、Pete Resnick、Meral Shirazipour和Bert Wijnen在IETF上次通话中提供了有用的评论。
Authors' Addresses
作者地址
Hannes Tschofenig Austria
奥地利汉内斯·茨霍芬尼
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
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@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Bernard Aboba (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 United States
Bernard Aboba（编辑）微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernard_aboba@hotmail.com
EMail: bernard_aboba@hotmail.com