ECRIT                                                     H. Schulzrinne
Internet-Draft                                       Columbia University
Intended status: Standards Track                               S. McCann
Expires: May 7, 2009                         Siemens/Roke Manor Research
                                                                G. Bajko
                                                                   Nokia
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                        November 3, 2008


   Extensions to the Emergency Services Architecture for dealing with
                Unauthenticated and Unauthorized Devices
         draft-schulzrinne-ecrit-unauthenticated-access-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 7, 2009.

Abstract

   The IETF emergency services architecture assumes that the calling
   device has acquired rights to use the access network or that no
   authentication is required for the access network, such as for public
   wireless access points.  Subsequent protocol interactions, such as
   obtaining location information, learning the address of the Public
   Safety Answering Point (PSAP) and the emergency call itself are



Schulzrinne, et al.        Expires May 7, 2009                  [Page 1]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   largely decoupled from the underlying network access procedures.

   In some cases, the device does not have credentials for network
   access, does not have a VoIP provider, or the credentials have become
   invalid, e.g., because the user has exhausted their prepaid balance
   or the account has expired.

   This document provides a problem statement, introduces terminology
   and describes an extension for the base IETF emergency services
   architecture to address these scenarios.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  No Access Authorization (NAA)  . . . . . . . . . . . . . .  5
     1.2.  No VoIP Service Provider (NVP) . . . . . . . . . . . . . .  6
     1.3.  Zero-Balance VoIP Service Provider (ZBP) . . . . . . . . .  6
   2.  A Warning Note . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Considerations for ISPs to support Unauthenticated
       Emergency Services without Architecture Extensions . . . . . .  7
   5.  Considerations for ISPs to support Unauthenticated
       Emergency Services with Architecture Extensions  . . . . . . .  8
   6.  Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  End Host Profile . . . . . . . . . . . . . . . . . . . . . 12
       6.1.1.  LoST Server Discovery  . . . . . . . . . . . . . . . . 12
       6.1.2.  ESRP Discovery . . . . . . . . . . . . . . . . . . . . 12
       6.1.3.  Location Determination and Location Configuration  . . 12
       6.1.4.  Emergency Call Identification  . . . . . . . . . . . . 12
       6.1.5.  SIP Emergency Call Signaling . . . . . . . . . . . . . 13
       6.1.6.  Media  . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.1.7.  Testing  . . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  IAP/ISP Profile  . . . . . . . . . . . . . . . . . . . . . 13
       6.2.1.  ESRP Discovery . . . . . . . . . . . . . . . . . . . . 13
       6.2.2.  Location Determination and Location Configuration  . . 13
     6.3.  ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 14
       6.3.1.  Emergency Call Routing . . . . . . . . . . . . . . . . 14
       6.3.2.  Emergency Call Identification  . . . . . . . . . . . . 14
       6.3.3.  SIP Emergency Call Signaling . . . . . . . . . . . . . 14
       6.3.4.  Location Retrieval . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18



Schulzrinne, et al.        Expires May 7, 2009                  [Page 2]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   Intellectual Property and Copyright Statements . . . . . . . . . . 19


















































Schulzrinne, et al.        Expires May 7, 2009                  [Page 3]


Internet-Draft      Unauthenticated Emergency Service      November 2008


1.  Introduction

   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 older 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.

   Roughly speaking, the IETF emergency services architecture (see
   [I-D.ietf-ecrit-phonebcp] and [I-D.ietf-ecrit-framework]) divides
   responsibility for handling emergency calls between the access
   network (ISP), the VoIP service provider (VSP) and the provider of
   emergency signaling services, the emergency service network (ESN).
   The access network may provide location information to end systems,
   but does not have to provide any VoIP signaling functionality.  The
   emergency caller can reach the ESN either directly or through the
   VoIP provider's outbound proxy.  Any of the three parties can provide
   the mapping from location to PSAP URI by offering LoST [RFC5222]
   services.

   In general, a set of automated configuration mechanisms allows a
   device to function in a variety of architectures, without the user
   being aware of the details on who provides location, mapping services
   or call routing services.  However, if emergency calling is to be
   supported when the calling device lacks access network authorization
   or does not have a VoIP provider, one or more of the providers may
   need to provide additional services and functions.

   In all cases, the end device MUST be able to perform a LoST lookup
   and otherwise conduct the emergency call in the same manner as when
   the three exceptional conditions discussed below do not apply.

   We distinguish between three conditions:

   No access authorization (NAA):  The current access network requires
      access authorization and the caller does not have valid user
      credentials.  (This includes the case where the access network
      allows pay-per-use, as is common for wireless hotspots, but there
      is insufficient time to pay for access.)








Schulzrinne, et al.        Expires May 7, 2009                  [Page 4]


Internet-Draft      Unauthenticated Emergency Service      November 2008


    No VoIP provider (NVP):  The caller does not have a VoIP service
      provider (VSP) at the time of the call.

   Zero-balance VoIP provider (ZBP):  The caller has valid credentials
      with a VSP, but is not allowed to place calls, e.g., because the
      user has a zero balance in a prepaid account.


   A user may well suffer from both NAA and NVP or ZBP at the same time.
   Depending on local policy and regulations, it may not be possible to
   place emergency calls in the NAA case.  Unless local regulations
   require user identification, it should always be possible to place
   calls in the NVP case, with minimal impact on the ISP.  Unless the
   ESN requires that all calls traverse a known set of VSPs, a caller
   should be able to place an emergency call in the ZBP case.  We
   discuss each case in separate sections below.

1.1.  No Access Authorization (NAA)

   In the NAA (No Access Authorization) case, the emergency caller does
   not posses valid credentials for the access network.  If local
   regulations or policy allows or require, the access network may or
   needs to cooperate in providing emergency calling services.
   Generally, the ISP will want to ensure that devices do not pretend to
   place emergency calls, but then abuse the access for obtaining more
   general services fraudulently.

   In particular, the ISP MUST allow emergency callers to acquire an IP
   address and to reach a LoST server, either provided by the ISP or
   some third party.  It SHOULD also provide location information via
   one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without
   requiring authorization unless it can safely assume that all nodes in
   the access network can determine their own location, e.g., via GPS.

   The details of how filtering is performed depends on the details of
   the ISP architecture and are beyond the scope of this document.  We
   illustrate a possible model.  If the ISP runs its own LoST server, it
   would maintain an access control list including all IP addresses
   contained in responses returned by the LoST server, as well as the
   LoST server itself.  (It may need to translate the domain names
   returned to IP addresses and hope that the resolution captures all
   possible DNS responses.)  Since the media destination addresses are
   not predictable, the ISP also has to provide a SIP outbound proxy so
   that it can determine the media addresses and add those to the filter
   list.






Schulzrinne, et al.        Expires May 7, 2009                  [Page 5]


Internet-Draft      Unauthenticated Emergency Service      November 2008


1.2.  No VoIP Service Provider (NVP)

   In the second case, the emergency caller has no current VoIP service
   provider (VSP).  This case poses no particular difficulties unless it
   is assumed that only VSPs provide LoST server or that ESNs only
   accept calls that reach it through a set of known VSPs.  However,
   since the calling device cannot obtain configuration information from
   its VSP, the ISP MUST provide the address of a LoST server via DHCP
   [RFC5223] if this model is to be supported.  The LoST server may be
   operated either by the ISP or a third party.

1.3.  Zero-Balance VoIP Service Provider (ZBP)

   In the case of zero-balance VoIP service provider, the VSP can
   authenticate the caller, but the caller is not authorized to place
   regular VoIP calls, e.g., because the contract has expired or the
   prepaid account for the customer has been depleted.  Naturally, a VSP
   can simply disallow access by such customers, so that all such
   customers find themselves in the NVP situation described above.  If
   VSPs desire or are required by regulation to provide emergency
   calling services to such customers, they need to provide LoST
   services to such customers and may need to provide outbound SIP proxy
   services.  As usual, the calling device looks up the LoST server via
   SIP configuration.

   Unless the emergency call traverses a PSTN gateway or the VSP charges
   for IP-to-IP calls, there is little potential for fraud.  If the VSP
   also operates the LoST server, the outbound proxy MAY restrict
   outbound calls to the SIP URIs returned by the LoST server.  It is
   NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may
   change.


2.  A Warning Note

   At the time of writing there is no regulation in place that demands
   the functionality described in this memo.  SDOs have started their
   work on this subject in a proactive fashion in the anticipation that
   national regulation will demand it for a subset of network
   environments.

   There are also indications that the functionality of unauthenticated
   emergency calls (called SIM-less calls) in today's cellular system in
   certain countries leads to a fair amount of hoaks or test calls.
   This causes overload situations at PSAPs with .






Schulzrinne, et al.        Expires May 7, 2009                  [Page 6]


Internet-Draft      Unauthenticated Emergency Service      November 2008


      As an example, Federal Office of Communications (OFCOM,
      Switzerland) provided statistics about 112 calls in Switzerland
      from Jan. 1997 to Nov. 2001.  Switzerland did not offer SIM-less
      emergency calls except for almost a month in July 2000 where a
      significant increase in hoaks and test calls was reported.  As a
      consequence, the functionality was disabled again.  More details
      can be found in the panel presentations of the 3rd SDO Emergency
      Services Workshop [esw07].


3.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119
   [RFC2119].

   This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps]
   and [RFC5012], namely Internet Access Provider (IAP), Internet
   Service Provider (ISP), Application Service Provider (ASP), Voice
   Service Provider (VSP), Emergency Service Routing Proxy (ESRP),
   Public Safety Answering Point (PSAP), Location Configuration Server
   (LCS), (emergency) service dial string, and (emergency) service
   identifier.


4.  Considerations for ISPs to support Unauthenticated Emergency
    Services without Architecture Extensions

   On a very high-level, the steps to be performed by an end host not
   being attached to the network and the user starting to make an
   emergency call are the following:

   o  Some radio networks have added support for unauthenticated
      emergency access, some other type of networks advertise these
      capabilities using layer beacons.  The end host learns about these
      unauthenticated emergency services capabilities either from the
      link layer type or from advertisement.
   o  The end host uses the link layer specific network attachment
      procedures defined for unauthenticated network access in order to
      get access to emergency services.
   o  When the link layer network attachment procedure is completed the
      end host learns basic configuration information using DHCP from
      the ISP, including the address of the LoST server.
   o  The end host MUST use a Location Configuration Protocol (LCP)
      supported by the IAP or ISP to learn its own location.





Schulzrinne, et al.        Expires May 7, 2009                  [Page 7]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   o  The end host MUST use the LoST protocol [I-D.ietf-ecrit-lost] to
      query the LoST server and ask for the PSAP URI responsible for
      that location.
   o  After the PSAP URI has been returned to the end host, the SIP UA
      in the end host directly initiates a SIP INVITE towards the PSAP
      URI.

   The IAP and the ISP will probably want to make sure that the claimed
   emergency caller indeed performs an emergency call rather than using
   the network for other purposes, and thereby acting fraudulent by
   skipping any authentication, authorization and accounting procedures.
   By restricting access of the unauthenticated emergency caller to the
   LoST server and the PSAP URI, traffic can be restricted only to
   emergency calls.

   Using the above procedures, the unauthenticated emergency caller will
   be successful only if:

   o  the ISP (or the IAP) support an LCP that the end host can use to
      learn its location.  A list of mandatory-to-implement LCPs can be
      found in [I-D.ietf-ecrit-phonebcp]).
   o  the ISP configures it's firewalls appropriately to allow emergency
      calls to traverse the network towards the PSAP.

   Some IAPs/ISPs may not be able to fulfill the above requirements.  If
   those IAPs/ISPs want to support unauthenticated emergency calls, then
   they can deploy an extended architecture as described in Section 5.


5.  Considerations for ISPs to support Unauthenticated Emergency
    Services with Architecture Extensions

   For unauthenticated emergency services support it is insufficient to
   provide mechanisms only at the link layer in order to bypass
   authentication for the cases when:

   o  the IAP/ISP does not support any Location Configuration Protocol
   o  the IAP/ISP does not have knowledge of a LoST server (which would
      assist the client to find the correct PSAP)

   A modification to the emergency services architecture is necessary
   since the IAP and the ISP need to make sure that the claimed
   emergency caller indeed performs an emergency call rather than using
   the network for other purposes, and thereby acting fraudulent by
   skipping any authentication, authorization and accounting procedures.
   Hence, without introducing some understanding of the specific
   application the ISP (and consequently the IAP) will not be able to
   detect and filter malicious activities.  This leads to the



Schulzrinne, et al.        Expires May 7, 2009                  [Page 8]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   architecture described in Figure 1 where the IAP needs to implement
   extensions to link layer procedures for unauthenticated emergency
   service access and the ISP needs to deploy emergency services related
   entities used for call routing, such as the Emergency Services
   Routing Proxy (ESRP), a Location Configuration Server (LCS) and a
   mapping database.

   On a very high-level, the interaction is as follows starting with the
   end host not being attached to the network and the user starting to
   make an emergency call.

   o  Some radio networks have added support for unauthenticated
      emergency access, some other type of networks advertise these
      capabilities using layer beacons.  The end host learns about these
      unauthenticated emergency services capabilities either from the
      link layer type or from advertisement.
   o  The end host uses the link layer specific network attachment
      procedures defined for unauthenticated network access in order to
      get access to emergency services.
   o  When the link layer network attachment procedure is completed the
      end host learns basic configuration information using DHCP from
      the ISP, including the address of the ESRP, as shown in (2).
   o  When the IP address configuration is completed then the SIP UA
      initiates a SIP INVITE towards the indicated ESRP, as shown in
      (3).  The INVITE message contains all the necessary parameters
      required by Section 6.1.5.
   o  The ESRP receives the INVITE and processes it according to the
      description in Section 6.3.3.  The location of the end host may
      need to be determined using a protocol interaction shown in (4).
   o  Potentially, an interaction between the LCS of the ISP and the LCS
      of the IAP may be necessary, see (5).
   o  Finally, the correct PSAP for the location of the end host has to
      be evaluated, see (6).
   o  The ESRP routes the call to the PSAP, as shown in (7).
   o  The PSAP evaluates the initial INVITE and aims to complete the
      call setup.
   o  Finally, when the call setup is completed media traffic can be
      exchanged between the PSAP and the emergency caller.

   For editorial reasons the end-to-end SIP and media exchange between
   the PSAP and SIP UA are not shown in Figure 1.

   Two important aspects are worth to highlight:

   o  The IAP/ISP needs to understand the concept of emergency calls and
      the SIP profile described in this document.  No other VoIP
      protocol profile, such as XMPP, Skype, etc., are supported for
      emergency calls in this particular architecture.  Other profiles



Schulzrinne, et al.        Expires May 7, 2009                  [Page 9]


Internet-Draft      Unauthenticated Emergency Service      November 2008


      may be added in the future, but the deployment effort is enormous
      since they have to be universally deployed.
   o  The end host has no obligation to determine location information.
      It may attach location information if it has location available
      (e.g., from a GPS receiver).

   Figure 1 shows that the ISP needs to deploy SIP-based emergency
   services functionality.  It is important to note that the ISP itself
   may outsource the functionality by simply providing access to them
   (e.g., it puts the IP address of an ESRP or a LoST server into an
   allow-list).  For editorial reasons this outsourcing is not shown.








































Schulzrinne, et al.        Expires May 7, 2009                 [Page 10]


Internet-Draft      Unauthenticated Emergency Service      November 2008


         +---------------------------+
         |                           |
         | Emergency Network         |
         | Infrastructure            |
         |                           |
         | +----------+ +----------+ |
         | | PSAP     | | ESRP     | |
         | |          | |          | |
         | +----------+ +----------+ |
         +-------------------^-------+
                             |
                             | (7)
    +------------------------+-----------------------+
    | ISP                    |                       |
    |                        |                       |
    |+----------+            v                       |
    || Mapping  |  (6)  +----------+                 |
    || Database |<----->| ESRP /   |                 |
    |+----------+       | SIP Proxy|<-+              |
    |+----------+       +----------+  |  +----------+|
    || LCS-ISP  |          ^          |  | DHCP     ||
    ||          |<---------+          |  | Server   ||
    |+----------+     (4)             |  +----------+|
    +-------^-------------------------+-----------^--+
    +-------|-------------------------+-----------|--+
    | IAP   | (5)                     |           |  |
    |       V                         |           |  |
    |+----------+                     |           |  |
    || LCS-IAP  |       +----------+  |           |  |
    ||          |       | Link     |  |(3)        |  |
    |+----------+       | Layer    |  |           |  |
    |                   | Device   |  |        (2)|  |
    |                   +----------+  |           |  |
    |                        ^        |           |  |
    |                        |        |           |  |
    +------------------------+--------+-----------+--+
                             |        |           |
                          (1)|        |           |
                             |        |           |
                             |   +----+           |
                             v   v                |
                        +----------+              |
                        | End      |<-------------+
                        | Host     |
                        +----------+

                            Figure 1: Overview




Schulzrinne, et al.        Expires May 7, 2009                 [Page 11]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   It is important to note that a single ESRP may also offer it's
   service to several ISPs.


6.  Profiles

6.1.  End Host Profile

6.1.1.  LoST Server Discovery

   The end host MAY attempt to use [I-D.ietf-ecrit-lost] to discover a
   LoST server.  If that attempt fails, the end host SHOULD attempt to
   discover the address of an ESRP.

6.1.2.  ESRP Discovery

   The end host only needs an ESRP when location configuration or LoST
   server discovery fails.  If that is the case, then the end host MUST
   use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option
   for Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6)
   and / or the "Dynamic Host Configuration Protocol (DHCPv6) Options
   for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover
   the address of an ESRP.  This SIP proxy located in the ISP network
   will be used as the ESRP for routing emergency calls.  There is no
   need to discovery a separate SIP proxy with specific emergency call
   functionality since the internal procedure for emergency call
   processing is subject of ISP internal operation.

6.1.3.  Location Determination and Location Configuration

   The end host SHOULD attempt to use the supported LCPs to configure
   its location.  If no LCP is supported in the end host or the location
   configuration is not successful, then the end host MUST attempt to
   discover an ESRP, which would assist the end host in providing the
   location to the PSAP.

   The SIP UA in the end host SHOULD attach the location information in
   a PIDF-LO [RFC4119] when making an emergency call.  When constructing
   the PIDF-LO the guidelines in PIDF-LO profile
   [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed.  For civic
   location information the format defined in [RFC5139] MUST be
   supported.

6.1.4.  Emergency Call Identification

   To determine which calls are emergency calls, some entity needs to
   map a user entered dialstring into this URN scheme.  A user may
   "dial" 1-1-2, but the call would be sent to urn:service:sos.  This



Schulzrinne, et al.        Expires May 7, 2009                 [Page 12]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   mapping SHOULD be performed at the endpoint device.

   End hosts MUST use the Service URN mechanism [RFC5031] to mark calls
   as emergency calls for their home emergency dial string (if known).
   For visited emergency dial string the translation into the Service
   URN mechanism is not mandatory since the ESRP in the ISPs network
   knows the visited emergency dial strings.

6.1.5.  SIP Emergency Call Signaling

   SIP signaling capabilities [RFC3261] are mandated for end hosts.

   The initial SIP signaling method is an INVITE.  The SIP INVITE
   request MUST be constructed according to the requirements in Section
   9.2 [I-D.ietf-ecrit-phonebcp].

   Regarding callback behavior SIP UAs MUST have a globally routable URI
   in a Contact: header.

6.1.6.  Media

   End points MUST comply with the media requirements for end points
   placing an emergency call found in Section 14 of
   [I-D.ietf-ecrit-phonebcp].

6.1.7.  Testing

   The description in Section 15 of [I-D.ietf-ecrit-phonebcp] is fully
   applicable to this document.

6.2.  IAP/ISP Profile

6.2.1.  ESRP Discovery

   An ISP hosting an ESRP MUST implement the server side part of
   "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for
   Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and /
   or the "Dynamic Host Configuration Protocol (DHCPv6) Options for
   Session Initiation Protocol (SIP) Servers" [RFC3319].

6.2.2.  Location Determination and Location Configuration

   The ISP not hosting an ESRP MUST support at least one widely used
   LCP.  The ISP hosting an ESRP MUST perform the neccesary steps to
   determine the location of the end host.  It is not necessary to
   standardize a specific mechanism.

   The role of the ISP is to operate the LIS.  The usage of HELD



Schulzrinne, et al.        Expires May 7, 2009                 [Page 13]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   [I-D.ietf-geopriv-http-location-delivery] with the identity
   extensions [I-D.winterbottom-geopriv-held-identity-extensions] may be
   a possible choice.  It might be necessary for the ISP to talk to the
   IAP in order to determine the location of the end host.  The work on
   LIS-to-LIS communication may be relevant, see
   [I-D.winterbottom-geopriv-lis2lis-req].

6.3.  ESRP Profile

6.3.1.  Emergency Call Routing

   The ESRP must route the emergency call to the PSAP responsible for
   the physical location of the end host.  However, a standardized
   approach for determining the correct PSAP based on a given location
   is useful but not mandatory.

   For cases where a standardized protocol is used LoST
   [I-D.ietf-ecrit-lost] is a suitable mechanism.

6.3.2.  Emergency Call Identification

   The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e.,
   the 'urn:service:sos' tree) and additionally the national emergency
   dial strings.  The ESRP SHOULD perform a mapping of national
   emergency dial strings to Service URNs to simplify processing at
   PSAPs.

6.3.3.  SIP Emergency Call Signaling

   SIP signaling capabilities [RFC3261] are mandated for the ESRP.  The
   ESRP MUST process the messages sent by the client, according to
   Section 6.1.5.  Furthermore, the ESRP MUST be able to add a reference
   to location information, as described in SIP Location Conveyance
   [I-D.ietf-sip-location-conveyance], before forwarding the call to the
   PSAP.  The ISP MUST be prepared to receive incoming dereferencing
   requests to resolve the reference to the location information.

6.3.4.  Location Retrieval

   The ESRP acts a location recipient and the usage of HELD
   [I-D.ietf-geopriv-http-location-delivery] with the identity
   extensions [I-D.winterbottom-geopriv-held-identity-extensions] may be
   a possible choice.  The ESRP would thereby act as a HELD client and
   the corresponding LIS at the ISP as the HELD server.

   The ESRP needs to obtain enough information to route the call.  The
   ESRP itself, however, does not necessarily need to process location
   information obtained via HELD since it may be used as input to LoST



Schulzrinne, et al.        Expires May 7, 2009                 [Page 14]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   to obtain the PSAP URI.


7.  Security Considerations

   The security threats discussed in [RFC5069] are applicable to this
   document.  A number of security vulnerabilities discussed in
   [I-D.barnes-geopriv-lo-sec] around faked location information are
   less problematic in this case since location information does not
   need to be provided by the end host itself or it can be verified to
   fall within a specific geographical area.

   There are a couple of new vulnerabilities raised with unauthenticated
   emergency services since the PSAP operator does is not in possession
   of any identity information about the emergency call via the
   signaling path itself.  In countries where this functionality is used
   for GSM networks today this has lead to a significant amount of
   misuse.

   The link layer mechanisms need to provide a special way of handling
   unauthenticated emergency services.  Although this subject is not a
   topic for the IETF itself but there are at least a few high-level
   assumptions that may need to be collected.  This includes security
   features that may be desirable.


8.  Acknowledgments

   Section 6 of this document is derived from [I-D.ietf-ecrit-phonebcp].
   The WiMax Forum contributed parts of the terminology.  Participants
   of the 2nd and 3rd SDO Emergency Services Workshop provided helpful
   input.


9.  IANA Considerations

   This document does not require actions by IANA.


10.  References

10.1.  Normative References

   [I-D.ietf-sip-location-conveyance]
              Polk, J. and B. Rosen, "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-11 (work in progress),
              October 2008.



Schulzrinne, et al.        Expires May 7, 2009                 [Page 15]


Internet-Draft      Unauthenticated Emergency Service      November 2008


   [RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services", RFC 5031,
              January 2008.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [I-D.ietf-geopriv-pdif-lo-profile]
              Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              PIDF-LO Usage Clarification, Considerations and
              Recommendations", draft-ietf-geopriv-pdif-lo-profile-13
              (work in progress), September 2008.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [RFC3361]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCP-for-IPv4) Option for Session Initiation Protocol
              (SIP) Servers", RFC 3361, August 2002.

   [RFC3319]  Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
              Protocol (DHCPv6) Options for Session Initiation Protocol
              (SIP) Servers", RFC 3319, July 2003.

   [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.

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

   [I-D.ietf-ecrit-phonebcp]
              Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in support of Emergency  Calling",
              draft-ietf-ecrit-phonebcp-05 (work in progress),
              July 2008.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.

   [RFC5223]  Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
              Location-to-Service Translation (LoST) Servers Using the
              Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
              August 2008.




Schulzrinne, et al.        Expires May 7, 2009                 [Page 16]


Internet-Draft      Unauthenticated Emergency Service      November 2008


10.2.  Informative References

   [I-D.ietf-ecrit-lost]
              Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", draft-ietf-ecrit-lost-10 (work in progress),
              May 2008.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
              progress), June 2008.

   [I-D.ietf-ecrit-framework]
              Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
              "Framework for Emergency Calling using Internet
              Multimedia", draft-ietf-ecrit-framework-06 (work in
              progress), July 2008.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-10 (work in
              progress), October 2008.

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

   [I-D.winterbottom-geopriv-held-identity-extensions]
              Winterbottom, J., "HELD Identity Extensions",
              draft-winterbottom-geopriv-held-identity-extensions-06
              (work in progress), July 2008.

   [I-D.winterbottom-geopriv-lis2lis-req]
              Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
              Requirements", draft-winterbottom-geopriv-lis2lis-req-01
              (work in progress), November 2007.

   [RFC5069]  Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
              Shanmugam, "Security Threats and Requirements for
              Emergency Call Marking and Mapping", RFC 5069,
              January 2008.

   [I-D.barnes-geopriv-lo-sec]
              Barnes, R., Lepinski, M., Tschofenig, H., and H.
              Schulzrinne, "Additional Location Privacy Considerations",



Schulzrinne, et al.        Expires May 7, 2009                 [Page 17]


Internet-Draft      Unauthenticated Emergency Service      November 2008


              draft-barnes-geopriv-lo-sec-03 (work in progress),
              July 2008.

   [esw07]    "3rd SDO Emergency Services Workshop,
              http://www.emergency-services-coordination.info/2007Nov/",
              October 30th - November 1st 2007.


Authors' Addresses

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

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


   Stephen McCann
   Siemens/Roke Manor Research

   Email: stephen.mccann@roke.co.uk


   Gabor Bajko
   Nokia

   Email: Gabor.Bajko@nokia.com


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at








Schulzrinne, et al.        Expires May 7, 2009                 [Page 18]


Internet-Draft      Unauthenticated Emergency Service      November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

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


Intellectual Property

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

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

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











Schulzrinne, et al.        Expires May 7, 2009                 [Page 19]