One document matched: draft-ietf-ecrit-psap-callback-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3325 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY RFC3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3966 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml">
<!ENTITY RFC3969 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3969.xml">
<!ENTITY RFC4474 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY RFC4484 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4484.xml">
<!ENTITY RFC5012 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5012.xml">
<!ENTITY RFC5031 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY RFC5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5627 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5627.xml">
<!ENTITY I-D.ietf-ecrit-phonebcp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml">
<!ENTITY I-D.ietf-sip-saml PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-saml.xml">
<!ENTITY I-D.holmberg-emergency-callback-id PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.holmberg-emergency-callback-id.xml">
<!ENTITY I-D.ietf-ecrit-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-framework.xml">
]>
<rfc category="std" docName="draft-ietf-ecrit-psap-callback-03.txt"
ipr="trust200902">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no"?>
<?rfc compact="no"?>
<?rfc strict="no"?>
<front>
<title abbrev="PSAP Callback">Public Safety Answering Point (PSAP)
Callback</title>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<author fullname="Milan Patel" initials="M." surname="Patel">
<organization>InterDigital Communications</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
</postal>
<email>Milan.Patel@interdigital.com</email>
</address>
</author>
<date year="2011" />
<workgroup>ECRIT</workgroup>
<abstract>
<t>After an emergency call is completed (either prematurely terminated
by the emergency caller or normally by the call-taker) it is possible
that the call-taker feels the need for further communication.
For example, the call may have been dropped by accident
without the call-taker having sufficient information about the current
situation of a wounded person. A call-taker may trigger a callback
towards the emergency caller using the contact information provided with
the initial emergency call. This callback could, under certain
circumstances, be treated like any other call and as a consequence
it may get blocked by authorization policies or may get forwarded to an
answering machine.</t>
<t>The IETF emergency services architecture offers capabilities to
allow callbask to bypass authorization policies to reach the caller without
unnecessary delays. However, the mechanism specified prior to this document
supports only limited scenarios. This document
discusses some shortcomings, presents additional scenarios where better-than-normal
call treatment behavior would be desirable, and specifies a protocol solution.</t>
</abstract>
</front>
<middle>
<!-- ****************************************************************************************** -->
<section anchor="intro" title="Introduction">
<t>Summoning police, the fire department or an ambulance in emergencies
is one of the fundamental and most-valued functions of the telephone. As
telephone 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
legacy technology. New devices and services are being made available
that could be used to make a request for help, which are not traditional
telephones, and users are increasingly expecting them to be used to
place emergency calls.</t>
<t>An overview of the protocol interactions for emergency calling using the IETF emergency services architecture are described in <xref target="I-D.ietf-ecrit-framework"/> and <xref target="I-D.ietf-ecrit-phonebcp"/> specifies the technical details. As part of the emergency call setup procedure two important identifiers are conveyed to the PSAP call-taker's user agent, namely the Address-Of-Record (AoR), and the Globally Routable User Agent (UA) URIs (GRUU). RFC 3261 <xref target="RFC3261"/> defines the AoR as:
<list style="empty">
<t>
An address-of-record (AOR) is a SIP or SIPS URI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.
Typically, the location service is populated through
registrations. An AOR is frequently thought of as the "public
address" of the user.
</t>
</list>
In SIP systems a single user can have a number of user agents (handsets,
softphones, voicemail accounts, etc.) which are all referenced by the
same AOR. There are a number of cases in which it is desirable to
have an identifier which addresses a single user agent rather than
the group of user agents indicated by an AOR. The GRUU is such a unique user-
agent identifier, which is still globally routable. <xref target="RFC5627"/> specifies how to obtain and use GRUUs.
</t>
<t>Regulatory requirements demand that the emergency call itself
provides enough information to allow the call-taker to initiate a call
back to the emergency caller in case the call dropped or to interact
with the emergency caller in case of further questions.
The AoR and the GRUU serve this purpose.
The communication attempt by the PSAP
call-taker back to the emergency caller is called 'PSAP callback'.
</t>
<t>A PSAP callback may,
however,
be blocked by user configured whitelis or may be forwarded to an answering machine as SIP entities (SIP
proxies as well as the SIP UA itself) cannot differentiate the callback from any other SIP call establishing attempt from the SIP signaling message.</t>
<t>While there are no regulatory requirements at the time of writing of this specification there is the believe
that PSAP callbacks have to be treated in such a way that they reach the emergency caller.
For this purpose guidance for PSAP callback handling has been provided in Section 13 of <xref
target="I-D.ietf-ecrit-framework"></xref>:</t>
<t><list style="empty">
<t>A UA may be able to determine a PSAP call back by examining the
domain of incoming calls after placing an emergency call and
comparing that to the domain of the answering PSAP from the
emergency call. Any call from the same domain and directed to the
supplied Contact header or AoR after an emergency call should be
accepted as a callback from the PSAP if it occurs within a
reasonable time after an emergency call was placed.</t>
</list></t>
<t>This approach mimics a stateful packet filtering firewall and is
indeed helpful in a number of cases. It is also relatively simple to
implement. Unfortunately, it does not work in all SIP deployment scenarios.
In <xref target="scenarios"/> we describe scenarios where the currently
standardized approach is insufficient. In <xref target="solution"/> a solution is described.
</t>
</section>
<!-- ****************************************************************************************** -->
<section anchor="terminology" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>Emergency services related terminology is borrowed from <xref
target="RFC5012"></xref>.</t>
</section>
<!-- ****************************************************************************************** -->
<section anchor="scenarios" title="Callback Scenarios">
<t>This section illustrates a number of scenarios where the currently specified solution, as specified in <xref target="I-D.ietf-ecrit-phonebcp"/>, for preferential treatment of callbacks fails. As explained in <xref target="intro"/> a SIP entity examines an incoming PSAP call back by comparing the domain of the PSAP with the destination domain of the emergency call.</t>
<section title="Routing Asymmetry">
<t>In some deployment environments it is common to have incoming and
outgoing SIP messaging routed through different SIP entities. <xref target="asymmetry"/> shows this graphically whereby a VoIP provider uses different SIP proxies for inbound and for outbound call handling. Unless they two devices are state synchronized the callback hitting the inbound proxy would get treated like any other call since the emergency call established state information at the outbound proxy only. </t>
<t><figure anchor="asymmetry" title="Example for Routing Asymmetry">
<artwork>
<![CDATA[
,-------.
,' `.
,-------. / Emergency \
,' `. | Services |
/ VoIP \ I | Network |
| Provider | n | |
| | t | |
| | e | |
| +-------+ | r | |
+--+---|Inbound|<--+-----m | |
| | |Proxy | | e | +------+ |
| | +-------+ | d | |PSAP | |
| | | i | +--+---+ |
+----+ | | | a-+ | | |
| UA |<---+ | | t | | | |
| |----+ | | e | | | |
+----+ | | | | | | |
| | | P | | | |
| | | r | | | |
| | +--------+ | o | | | |
+--+-->|Outbound|--+---->v | | +--+---+ |
| |Proxy | | i | | +-+ESRP | |
| +--------+ | d | | | +------+ |
| | e || | |
| | r |+-+ |
\ / | |
`. ,' \ /
'-------' `. ,'
'-------'
]]></artwork>
</figure></t>
</section>
<section anchor="multistage" title="Multi-Stage Routing">
<t>Consider the following emergency call routing scenario shown in
<xref target="stages"></xref> where routing towards the PSAP occurs in
several stages. In this scenario we consider a SIP UA that uses LoST to learn
the next hop destination closer to the PSAP. This call is then sent to the user's VoIP provider.
The user's VoIP provider
receives the emergency call and creates state based on the destination domain, namely state.com.
It then routes it to the indicated ESRP.
When the ESRP receives it it needs to decide what the next hop is to get it closer to the PSAP.
In our example the next hop is the PSAP with the URI psap@town.com.</t>
<t>When a callback is sent from psap@town.com towards the emergency caller the call
will get normal treatment by the VoIP providers inbound proxy since the domain of the PSAP
does not match the stored state information.</t>
<t><figure anchor="stages" title="Example for Multi-Stage Routing">
<artwork><![CDATA[
,-------.
+----+ ,' `.
| UA |--- esrp1@foobar.com / Emergency \
+----+ \ | Services |
\ ,-------. | Network |
,' `. | |
/ VoIP \ | +------+ |
( Provider ) | |PSAP | |
\ / | +--+---+ |
`. ,' | |
'---+---' | | |
| |psap@town.com |
esrp@state.com | | |
| | | |
| | | |
| | +--+---+ |
+------------+---+ESRP | |
| +------+ |
| |
\ /
`. ,'
'-------'
]]></artwork>
</figure></t>
</section>
<section title="Call Forwarding">
<t>Imagine the following case where an emergency call enters an
emergency network (state.org) via an ERSP but then gets forwarded to a
different emergency services network (in our example to
police-town.org, fire-town.org or medic-town.org). The same
considerations apply when the the police, fire and ambulance networks
are part of the state.org sub-domains (e.g., police.state.org).</t>
<t>Similarly to the previous scenario the problem here is with the
wrong state information being established during the emergency call
setup procedure. A callback would originate in the police-town.org, fire-town.org or medic-town.org
domain whereas the emergency caller's SIP UA or the VoIP outbound proxy has
stored state.org.</t>
<t><figure anchor="fwd" title="Example for Call Forwarding">
<artwork><![CDATA[
,-------.
,' `.
/ Emergency \
| Services |
| Network |
| (state.org) |
| |
| |
| +------+ |
| |PSAP +--+ |
| +--+---+ | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +--+---+ | |
------------------+---+ESRP | | |
esrp-a@state.org | +------+ | |
| | |
| Call Fwd | |
| +-+-+---+ |
\ | | | /
`. | | | ,'
'-|-|-|-' ,-------.
Police | | | Fire ,' `.
+------------+ | +----+ / Emergency \
,-------. | | | | Services |
,' `. | | | | Network |
/ Emergency \ | Ambulance | | fire-town.org |
| Services | | | | | |
| Network | | +----+ | | +------+ |
|police-town.org| | ,-------. | +----+---+PSAP | |
| | | ,' `. | | +------+ |
| +------+ | | / Emergency \ | | |
| |PSAP +----+--+ | Services | | | ,
| +------+ | | Network | | `~~~~~~~~~~~~~~~
| | |medic-town.org | |
| , | | |
`~~~~~~~~~~~~~~~ | +------+ | |
| |PSAP +----+ +
| +------+ |
| |
| ,
`~~~~~~~~~~~~~~~
]]></artwork>
</figure></t>
</section>
<section title="Network-based Service URN Resolution">
<t>The IETF emergency services architecture also considers
cases where the resolution from the Service URN to the PSAP URI
does not only happen at the SIP UA itself but at intermedidate SIP entities,
such as the user's VoIP provider.</t>
<t><xref target="late-binding"></xref> shows this message exchange
of the outgoing emergency call and the incoming PSAP graphically.
While the state information stored at the VoIP provider is correct
the state allocated at the SIP UA is not. </t>
<t><figure anchor="late-binding"
title="Example for Network-based Service URN Resolution">
<artwork><![CDATA[
,-------.
,' `.
/ Emergency \
| Services |
| Network |
|police-town.org|
| |
| +------+ | Invite to police.example.com
| |PSAP +<---+------------------------+
| | +----+------------------+ ^
| +------+ |Invite from | |
| ,police.example.com| |
`~~~~~~~~~~~~~~~ v |
+--------+ ++-----+-+
| | query |VoIP |
| LoST |<-----------------------|Service |
| Server | police.example.com |Provider|
| |----------------------->| |
+--------+ +--------+
| ^
Invite| | Invite
from| | to
police.example.com| | urn:service:sos
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+
]]></artwork>
</figure></t>
</section>
<section title="PSTN Interworking">
<t>In case an emergency call enters the PSTN, as shown in <xref
target="pstn"></xref>, there is no guarantee that the callback some
time later does leave the same PSTN/VoIP gateway or that the same end
point identifier is used in the forward as well as in the backward
direction making it difficult to reliably detect PSAP callbacks.</t>
<t><figure anchor="pstn" title="Example for PSTN Interworking">
<artwork><![CDATA[
+-----------+
| PSTN |-------------+
| Calltaker | |
| Bob |<--------+ |
+-----------+ | v
-------------------
//// \\\\ +------------+
| | |PSTN / VoIP |
| PSTN |---->|Gateway |
\\\\ //// | |
------------------- +----+-------+
^ |
| |
+-------------+ | +--------+
| | | |VoIP |
| PSTN / VoIP | +->|Service |
| Gateway | |Provider|
| |<------Invite----| Y |
+-------------+ +--------+
| ^
| |
Invite Invite
| |
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+
]]></artwork>
</figure></t>
<t>Note: This scenario is considered outside the scope of this
document. The specified solution does not support this use case.</t>
</section>
</section>
<!-- ****************************************************************************************** -->
<section anchor="solution" title="Specification">
<t>[Editor's Note: The solution approach described in <xref target="I-D.holmberg-emergency-callback-id"/> will
be discussed at the IETF#82 ECRIT meeting and at the ECRIT mailing list and will be incorporated here
if agreed by the working group.]</t>
</section>
<!-- ****************************************************************************************** -->
<section title="Security Considerations">
<!--
<t>This document defines a callback marking scheme.
</t>
<t>An important aspect from a security point of view is the relationship
between the emergency services network and the VSP (assuming that the
emergency call travels via the VSP and not directly between the SIP UA
and the PSAP). If there is some form of relationship between the
emergency services operator and the VSP then the identification of a
PSAP call back is less problematic than in the case where the two
entities have not entered in some form of relationship that would allow
the VSP to verify whether the marked callback message indeed came from a
legitimate source.</t>
<t>The main attack surface can be seen in the usage of PSAP callback
marking to bypass blacklists, ignore call forwarding procedures and
similar features to interact with users and to get their attention. For
example, using PSAP callback marking devices would be able to recognize
these types of incoming messages leading to the device overriding user
interface configurations, such as vibrate-only mode. As such, the
requirement is to ensure that the mechanisms described in this document
can not be used for malicious purposes, including SPIT.</t>
<t>A SIP entity MAY treat the call as a normal incoming call if it
considers the request with the included URI parameter to be fraudulent,
i.e. if it does not recognize the originator, or the domain from where
the call originated from as being trusted/owned by a PSAP. It is NOT
RECOMMENDED to drop a call that is marked as PSAP callback in such a
case since this may severely impact the ability for calltakers at PSAPs
to contact emergency callers.</t>
-->
<t>[Editor's Note: Instead of an abstract security description text will be provided
with the solution description.]</t>
</section>
<!-- ****************************************************************************************** -->
<section anchor="iana" title="IANA Considerations">
<t>[Editor's Note: IANA consideration text will be added once an agreement on the solution has
been reached.</t>
</section>
<!-- ****************************************************************************************** -->
<section title="Acknowledgements">
<t>We would like to thank members from the ECRIT working group, in
particular Brian Rosen, for their discussions around PSAP callbacks. The
working group discussed the topic of callbacks at their virtual interim
meeting in February 2010 and the following persons provided valuable
input: John Elwell, Bernard Aboba, Cullen Jennings, Keith Drage, Marc
Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, Janet Gunn.</t>
<t>At IETF#81 a small group of people got to together to continue the
discussions started at the working group meeting to explore a
GRUU-based solution approach. Martin Thomson, Marc Linsner, Andrew Allen,
Brian Rosen, Martin Dolly, and Atle Monrad participated at this
side-meeting.</t>
<t>Finally, we would like to thank Cullen Jennings for his discussion
input. He was the first to propose a "token-based" solution.</t>
</section>
<!-- ****************************************************************************************** -->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3261;
&RFC3325;
&RFC3966;
&RFC3969;
&RFC5627;
<reference anchor="RFC5341">
<front>
<title>The Internet Assigned Number Authority (IANA) tel Uniform
Resource Identifier (URI) Parameter Registry</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization></organization>
</author>
<author fullname="Vijay K. Gurbani" initials="V. K. "
surname="Gurbani">
<organization></organization>
</author>
<date month="September" year="2008" />
</front>
</reference>
&RFC4474;
</references>
<references title="Informative References">
&I-D.ietf-ecrit-framework;
&I-D.ietf-ecrit-phonebcp;
&I-D.ietf-sip-saml;
&I-D.holmberg-emergency-callback-id;
&RFC4484;
&RFC5012;
&RFC5031;
&RFC5234;
</references>
<!-- ****************************************************************************************** -->
<section title="Alternative Solutions Considered">
<t>In an attempt to describe the problem and to explore solution approaches the
working group had also investigated alternative approaches. We document them here
for completeness. The solutions fall into three categories: (1) Identity-based authorization,
(2) Trait-based authorization, and (3) Call Marking. Even though these solutions are not
mutually exclusive we describe them in separate sub-sections.</t>
<t>Beyond the disadvantages listed in each solution category none of them
provides the emergency caller with the ability to restrict preferential PSAP callback
handling to those cases where an earlier emergency call was initiated. </t>
<section title="Identity-based Authorization">
<t>In <xref target="identity-authz"></xref> an interaction is presented
that allows a SIP entity to make a policy decision whether to bypass
installed authorization policies and thereby providing preferential
treatment. To make this decision the sender's identity is compared with
a whitelist of valid PSAPs. The identity assurances in SIP can come in
different forms, such as SIP Identity <xref target="RFC4474"></xref> or
with P-Asserted-Identity <xref target="RFC3325"></xref>. The former
technique relies on a cryptographic assurance and the latter on a chain
of trust.</t>
<t><figure anchor="identity-authz" title="Identity-based Authorization">
<artwork><![CDATA[
+----------+
| List of |+
| valid ||
| PSAP ids ||
+----------+|
+----------+
*
* whitelist
*
V
Incoming +----------+ Normal
SIP Msg | SIP |+ Treatment
-------------->| Entity ||=============>
+ Identity | ||(if not in whitelist)
+----------+|
+----------+
||
||
|| Preferential
|| Treatment
++=============>
(in whitelist)
]]></artwork>
</figure></t>
<t>This approach was not chosen because the establishment of a whitelist containing PSAP identities is
operationally complex and does not easily scale world wide. Only when there
is a local relationship between the VSP/ASP and the PSAP then populating
the whitelist is far simpler. This would, however, constrain the applicability of the mechanism considerably.</t>
</section>
<section title="Trait-based Authorization">
<t>An alternative approach to an identity based authorization model is
outlined in <xref target="trait"></xref>. In fact, RFC 4484 <xref
target="RFC4484"></xref> illustrates a related emergency service use case.</t>
<t><figure anchor="trait" title="Trait-based Authorization">
<artwork><![CDATA[
+----------+
| List of |+
| trust ||
| anchor ||
+----------+|
+----------+
*
*
*
V
Incoming +----------+ Normal
SIP Msg | SIP |+ Treatment
-------------->| Entity ||=============>
+ trait | ||(no indication
+----------+| of PSAP)
+----------+
||
||
|| Preferential
|| Treatment
++=============>
(indicated as
PSAP)
]]></artwork>
</figure></t>
<t>In a trait-based authorization scenario an incoming SIP message
contains a form of trait, i.e. some form of assertion. The assertion
contains an indication that the sending party has the role of a PSAP (or
similar emergency services entity). The assertion is either
cryptographically protected to enable end-to-end verification or an
chain of trust security model has to be assumed. In <xref
target="trait"></xref> we assume an end-to-end security model where
trust anchors are provisioned to ensure the ability for a SIP entity to
verify the received assertion.</t>
<t>This solution was not chosen because trait-based authorization never got
deployed in SIP. Furthermore, in order to ensure that the assertions are
properly protected it is necessary to digitally sign, which requires some
form of public key infrastructure for usage with emergency services.
Finally, there need to be some policies in place that define which entities
are allowed to obtain various roles. These policies and procedures do not
exist today.</t>
</section>
<section title="Call Marking">
<t>
Call marking allows the PSAP to place a non-cryptographic label
on outgoing calls that gives, when received by a SIP entity, preferential
treatment for these callbacks. </t>
<t>When used in isolation this mechanism introduces considerable denial of
service attacks due to the ability to bypass any authorization policies
and could be utilized to distribute unwanted traffic.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:33:29 |