ECRIT                                                     H. Schulzrinne
Internet-Draft                                       Columbia University
Intended status: Standards Track                               S. McCann
Expires: March 25, April 28, 2011                        Research in Motion UK Ltd
                                                                G. Bajko
                                                                   Nokia
                                                           H. Tschofenig
                                                          D. Kroeselberg
                                                  Nokia Siemens Networks
                                                      September 21,
                                                        October 25, 2010

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

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
   largely decoupled from the underlying network access procedures.

   In some cases, however, the device does not have these credentials
   for network access, does not have a VoIP provider or application service provider
   (ASP), 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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 25, April 28, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  No Access Authorization (NAA)
   2.  Terminology  . . . . . . . . . . . . . .  5
     1.2.  No ASP (NASP) . . . . . . . . . . .  6
   3.  Use Case Categories  . . . . . . . . . . . . . . . .  6
     1.3.  Zero-Balance Application Service Provider (ZBP) . . . . .  6
   2.  A Warning Note
   4.  ZBP Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   5.  NASP Considerations  . .  6
   3.  Terminology . . . . . . . . . . . . . . . . . . .  9
     5.1.  End Host Profile . . . . . . .  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.  NAA considerations for the network attachment procedure of
       IAPs/ISPs . 11
       5.1.1.  LoST Server Discovery  . . . . . . . . . . . . . . . . 11
       5.1.2.  ESRP Discovery . . . . . . . . . 12
     6.1.  Link layer emergency indication . . . . . . . . . . . 11
       5.1.3.  Location Determination and Location Configuration  . . 12
     6.2.  Higher-layer emergency indication 11
       5.1.4.  Emergency Call Identification  . . . . . . . . . . . . 13
     6.3.  Securing network attachment in NAA cases 11
       5.1.5.  SIP Emergency Call Signaling . . . . . . . . . 14
   7.  Profiles . . . . 12
       5.1.6.  Media  . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  End Host Profile . 12
       5.1.7.  Testing  . . . . . . . . . . . . . . . . . . . . 16
       7.1.1.  LoST Server Discovery . . . 12
     5.2.  IAP/ISP Profile  . . . . . . . . . . . . . . . . . . . . . 16
       7.1.2. 12
       5.2.1.  ESRP Discovery . . . . . . . . . . . . . . . . . . . . 16
       7.1.3. 12
       5.2.2.  Location Determination and Location Configuration  . . 16
       7.1.4.  Emergency Call Identification 12
     5.3.  ESRP Profile . . . . . . . . . . . . 16
       7.1.5.  SIP Emergency Call Signaling . . . . . . . . . . . 13
       5.3.1.  Emergency Call Routing . . 17
       7.1.6.  Media . . . . . . . . . . . . . . 13
       5.3.2.  Emergency Call Identification  . . . . . . . . . . 17
       7.1.7.  Testing . . 13
       5.3.3.  SIP Emergency Call Signaling . . . . . . . . . . . . . 13
       5.3.4.  Location Retrieval . . . . . . . . 17
     7.2.  IAP/ISP Profile . . . . . . . . . . 13
   6.  Lower Layer Considerations for NAA Case  . . . . . . . . . . . 17
       7.2.1.  ESRP Discovery 14
     6.1.  Link Layer Emergency Indication  . . . . . . . . . . . . . 14
     6.2.  Higher-Layer Emergency Indication  . . . . . . . 17
       7.2.2.  Location Determination and Location Configuration . . 17
     7.3.  ESRP Profile . . . 15
     6.3.  Securing Network Attachment in NAA Cases . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . 18
       7.3.1.  Emergency Call Routing . . . . . . . . 18
   8.  Acknowledgments  . . . . . . . . 18
       7.3.2.  Emergency Call Identification . . . . . . . . . . . . 18
       7.3.3.  SIP Emergency Call Signaling . . . 19
   9.  IANA Considerations  . . . . . . . . . . 18
       7.3.4.  Location Retrieval . . . . . . . . . . . 19
   10. References . . . . . . . 18
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments 19
     10.1. Normative References . . . . . . . . . . . . . . . . . . . . . . . 19
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2. Informative References 19
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22

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 application service provider (ASP) that may be a
   VoIP service provider and the provider of emergency signaling
   services, the emergency service network (ESN).  The access network
   may provide location information to end systems, but does not have to
   provide any ASP signaling functionality.  The emergency caller can
   reach the ESN either directly or through the ASP's outbound proxy.
   Any of the three parties can provide the mapping from location to
   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 an ASP, one or more of the providers may need to
   provide additional services and functions.

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

   We distinguish between three conditions:

   No access authorization Access Authentication (NAA):  The current access network requires
      access authorization and  In the NAA case, the emergency
      caller does not have posses valid user
      credentials.  (This credentials for the access network.
      This includes the case where the access network allows pay-per-use, pay-per-
      use, as is common for wireless hotspots, but there is insufficient
      time to pay enter credit card details and other registration
      information required for access.  It also covers all cases where
      either no credentials are available at all, or the available
      credentials do not work for the given IAP/ISP.  As a result, the
      NAA case basically combines the below NASP and ZBP cases, but at
      the IAP/ISP level.  Support for access.) emergency call handling in the NAA
      case is subject to the local policy of the ISP.  Such policy may
      vary substantially between ISPs and typically depends on external
      factors that are not under the ISP control.

   No ASP (NASP):  The caller does not have an ASP at the time of the
      call.

   Zero-balance ASP (ZBP):  The  This can occur either in case the caller has does not possess
      any valid credentials with an subscription for a reachable ASP, but is not allowed to access services like placing calls or in case none of a VoIP service, e.g., because the user has a zero balance
      in
      ASPs where the caller owns a prepaid account.

   A user may well suffer from both NAA and NASP or ZBP at valid subscription is reachable
      through the same
   time.  Depending ISP.

      Note: The interoperability need is increased with this scenario
      since the client software used by the emergency caller must be
      compatible with the protocols and extensions deployed by the ESN.

   Zero-balance ASP (ZBP):  In the case of zero-balance ASP, the ASP can
      authenticate the caller, but the caller is not authorized to use
      ASP services, e.g., because the contract has expired or the
      prepaid account for the customer has been depleted.

   These three cases are not mutually exclusive.  A caller in need for
   help may find himself/herself in, for example, a NAA and NASP
   situation, as explained in more details in Figure 1.  Depending on
   local policy and regulations, it may not be possible to place
   emergency calls in the NAA case.  Unless local regulations require
   user identification, it should always be possible to place calls in
   the NASP case, with minimal impact on the ISP.  Unless the ESN
   requires that all calls traverse a known set of VSPs, it is
   technically possible to let 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 more details in Section 3.

   Note: At the access network.  If local
   regulations or policy allows or requires support for emergency calls time of writing there is no regulation in NAA, place that
   demands the access network may or needs to cooperate functionality described in providing
   emergency calling services.  Support for NAA emergency calls is this memo.  SDOs have started
   their work on this subject to the local policy of in a proactive fashion in the ISP.  Such policy may vary
   substantially between ISPs and typically depends on external factors anticipation
   that national regulation will demand it for a subset of network
   environments.

   There are not under also indications that the ISP control.  Hence, no global mandates for
   supporting functionality of unauthenticated
   emergency calls (called SIM-less calls) in today's cellular system in relation
   certain countries leads to NAA can be made.  However,
   it makes a lot fair amount of sense hoax or test calls.  This
   causes overload situations at PSAPs which is considered harmful to offer appropriate building blocks that
   enable ISPs to flexibly react on the local environment.Generally,
   the
   ISP will want overall availability and reliability of emergency services.

   As an example, Federal Office of Communications (OFCOM, Switzerland)
   provided statistics about emergency (112) calls in Switzerland from
   Jan. 1997 to ensure that devices do Nov. 2001.  Switzerland did not pretend to place offer SIM-less emergency calls, but then abuse the access
   calls except for obtaining more general
   services fraudulently.

   In particular, the ISP MUST allow emergency callers to acquire an IP
   address almost a month in July 2000 where a significant
   increase in hoax and to reach test calls was reported.  As a LoST server, either provided by the ISP or
   some third party.  It SHOULD also provide location information via
   one of consequence, the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without
   requiring authorization unless it
   functionality was disabled again.  More details can safely assume that all nodes be found in the access network can determine their own location, e.g., via GPS.

   The details
   panel presentations of how filtering is performed depends on the details of 3rd SDO Emergency Services Workshop
   [esw07].

2.  Terminology

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

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

3.  Use Case Categories

   On a possible model.  If very high-level, the ISP runs its own LoST server, it
   would maintain steps to be performed by 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 end host not
   being attached to translate the domain names
   returned to IP addresses network and hope that the resolution captures all
   possible DNS responses.)  Since the media destination addresses user starting to make an
   emergency call are
   not predictable, the ISP also has to provide a SIP outbound proxy so
   that it can determine following:

   Link Layer Attachment:  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 media addresses and add those to link layer type or from advertisement.

      The end host uses the filter
   list.

1.2.  No ASP (NASP)

   In link layer specific network attachment
      procedures defined for unauthenticated network access in order to
      get access to the second case, network.

   Pre-Emergency Service Configuration:  When the emergency caller has no current ASP.  This
   case poses no particular difficulties unless it link layer network
      attachment procedure is assumed that only
   ASPs provide LoST server or that ESNs only accept calls that reach it
   through a set of known ASPs.  However, since completed the calling device
   cannot obtain end host learns basic
      configuration information using DHCP from its ASP, the ISP MUST
   provide ISP, including the
      address of the LoST server.  The end host uses a Location
      Configuration Protocol (LCP) to retrieve location information.
      Subsequently, the LoST server via DHCP [RFC5223] if this model protocol [RFC5222] is used to be supported.  The LoST server may be operated either by the
   ISP or a third party.

1.3.  Zero-Balance Application Service Provider (ZBP)

   In learn the case of zero-balance ASP,
      relevant emergency numbers, and to obtain the ASP can authenticate PSAP URI applicable
      for that location.

   Emergency Call:  In case of need for help, a user dials an emergency
      number and the caller,
   but SIP UA initiates the caller is not authorized to use ASP services, e.g., because emergency call procedures by
      communicating with the contract has expired or PSAP.

   Figure 1 compiles the prepaid account basic logic taking place during network entry
   for requesting an emergency service and shows the customer has
   been depleted. interrelation
   between the three conditions described in the above section.

                         +-----Y
                         |Start|
                         `...../
                            |
                            | Are credentials
                            | for network attachment
                            | available?
                            |
               NO           v         YES
             +----------------------------+
             |                            |
             |                            |
             V                            v
        ..............               ................
        | Idle: Wait |               |Execute       |
        | for ES Call|               |LLA Procedures|
        | Initiation |               "--------------'
        "------------'                    |
    Is        |               +---------->O
    emergency |               |           | Is ASP
    service   | NO +-----Y    |           | configured?
    network   +--->| End |    |           +---------------+
    attachment|    `...../    |       YES |               | NO
    possible? |               |           |               |
              v               |           v               v
        +------------+        |     +------------+    +------------+
        | Execute    |        |     | Execute    |    | Execute    |
        | NAA        |--------+     | Phone BCP  |    | NASP       |
        | Procedures |              | Procedures |    | Procedures |
        +------------+              +------------+    +------------+
                         Authorization for|                |
                         Emergency Call?  |                |
                           +--------------+                v
                           | NO           | YES         +-----Y
                           |              |             | Done|
                           v              v             `...../
                    +------------+  +------------+
                    | Execute    |  | Execute    |
                    | ZBP        |  | Phone BCP  |
                    | Procedures |  | Procedures |
                    +------------+  +------------+
                           |              |
                           |              |
                           v              v
                        +-----Y        +-----Y
                        | Done|        | Done|
                        `...../        `...../

   Abbreviations:
     LLA: Link Layer Attachment
     ES: Emergency Services

                          Figure 1: Flow Diagram

4.  ZBP Considerations

   Although subject to local regulatory mandates, it is expected that
   for most ASPs even with a lack of authorization for regular service
   an otherwise authenticated and known subscriber must be granted
   access to emergency services.  Naturally, without an obligation to
   support emergency services in ZBP cases an ASP can simply disallow
   access by such
   customers, so that customers.  As a result, all such customers find themselves in the subscribers may fall
   back into a NASP situation as described above.

   If ASPs desire or are required by regulation to provide emergency calling
   services to such customers,
   they need to provide LoST subscribers with valid credentials that only fail
   authorization, the emergency 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 nature of a PSTN gateway or call can easily be
   determined by inspecting the ASP charges
   for IP-to-IP calls, there is little potential call setup procedure for fraud.  If the ASP
   also operates presence of
   the LoST server, emergency service URNs.  This example shows that in the outbound proxy MAY restrict
   outbound calls context
   of this document no specific considerations apply to the SIP URIs returned by the LoST server.  It is
   NOT RECOMMENDED ZBP case due
   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 fact that demands the functionality described in this memo.  SDOs have started their
   work on this subject in a proactive fashion in ASP will be able to relate the anticipation that
   national regulation service request
   to an existing subscription or user and will demand it for a subset be in control of network
   environments.

   There are also indications
   adjusting any authorization decision based on its deployemnt specific
   policy.  It is, however, noted that specific security considerations
   apply due to the functionality of unauthenticated fact that emergency calls (called SIM-less calls) in today's cellular system service access will likely be
   granted with limited authorization only, see Section 7.

   ZBP cases in
   certain countries leads the context of this document cover all cases where an
   otherwise valid subscription lacks authorization to access or regular
   ASP services, i.e., a fair amount lack of hoax or test calls.  This
   causes overload situations at PSAPs which is considered harmful to authorization that would block the overall availability and reliability of
   subscriber from using the service for emergency services.

      As an example, Federal Office purpose.  Example ZBP
   cases include empty prepaid accounts, barred accounts, or certain
   roaming or mobility restrictions.  The exact list of Communications (OFCOM,
      Switzerland) provided statistics about cases where
   emergency (112) calls in
      Switzerland from Jan. 1997 services need to Nov. 2001.  Switzerland did not
      offer SIM-less emergency calls except for almost a month in July
      2000 where a significant increase in hoax and test calls was
      reported.  As a consequence, the functionality was disabled again.
      More details can be found in the panel presentations of the 3rd
      SDO Emergency Services Workshop [esw07].

3.  Terminology

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

   This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps] the
   ASP policy 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, deployment, and (emergency) service
   identifier.

4. is therefore beyond the scope of this
   document.

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

   This section provides a recommended configuration for unauthenticated
   emergency services support without architecture extensions.

   On a very high-level,

   To start the description we consider the sequence of steps to be performed by that are
   executed in an end host not
   being attached emergency call based on Figure 2.

   o  As an initial step the devices attaches to the network and the user starting to make an
   emergency call are as shown in
      step (1).  This step is outside 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. scope of this section.
   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. ESRP, as shown in step (2).
   o  The end host MUST use  When the IP address configuration is completed then the SIP UA
      initiates a Location Configuration Protocol (LCP)
      supported SIP INVITE towards the indicated ESRP, as shown in
      (3).  The INVITE message contains all the necessary parameters
      required by Section 5.1.5.
   o  The ESRP receives the IAP or ISP INVITE and processes it according to learn its own location.
   o the
      description in Section 5.3.3.  The location of the end host MUST use the LoST protocol [I-D.ietf-ecrit-lost] may
      need to
      query be determined using a protocol interaction shown in (4).
   o  Potentially, an interaction between the LoST server LCS of the ISP and asks for the PSAP URI responsible for
      that location. LCS
      of the IAP may be necessary, see (5).
   o  After  Finally, the correct PSAP URI for the location of the end host has been returned to
      be evaluated, see (6).
   o  The ESRP routes the end host, call to the SIP UA PSAP, as shown in (7).
   o  The PSAP evaluates the end host directly initiates a SIP initial INVITE towards the PSAP
      URI.

   The IAP and the ISP will probably want aims to make sure that complete the claimed
   emergency caller indeed performs an emergency
      call rather than using setup.
   o  Finally, when the network for other purposes, and thereby acting fraudulent by
   skipping any authentication, authorization call setup is completed media traffic can be
      exchanged between the PSAP and accounting procedures.
   By restricting access of the unauthenticated emergency caller to caller.

   For editorial reasons the
   LoST server end-to-end SIP and media exchange between
   the PSAP URI, traffic can be restricted only and SIP UA are not shown in Figure 2.

   Two important aspects are worth to highlight:

   o  The IAP/ISP needs to understand the concept of emergency calls (see also section 1.1).

   Using the above procedures, or
      other emergency applicationsand the unauthenticated SIP profile described in this
      document.  No other VoIP protocol profile, such as XMPP, Skype,
      etc., are supported for emergency caller will calls in this particular
      architecture.  Other profiles may be successful only if:

   o  the ISP (or added in the IAP) support an LCP that future, but the end host can use
      deployment effort is enormous since they have to
      learn its location.  A list of mandatory-to-implement LCPs can be
      found in [I-D.ietf-ecrit-phonebcp]). 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 2 shows that the ISP configures it's firewalls appropriately needs to allow deploy SIP-based emergency
      calls
   services functionality.  It is important to traverse the network towards note that the PSAP.

   Some IAPs/ISPs ISP itself
   may not be able to fulfill outsource the above requirements.  If
   those IAPs/ISPs want functionality by simply providing access to support unauthenticated emergency calls, then
   they can deploy them
   (e.g., it puts the IP address of an extended architecture as described in Section 5.

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

   This section provides ESRP or a recommended configuration for unauthenticated
   emergency services support without 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 cannot assume the end hosts to support a 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
   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 7.1.5.
   o  The ESRP receives the INVITE and processes it according to the
      description in Section 7.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 or
      other emergency applicationsand 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 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). LoST server into an
   allow-list).  For editorial reasons this outsourcing is not shown.

         +---------------------------+
         |

            +-------+       +-------+
            | PSAP  | Emergency Network         |  (7)  | Infrastructure ESRP  |
            |       |<----->|       |
            +-------+       +-------+
                              ^
                              | (7)
                              v
      +----------+  (6)  +----------+
      |
         | | PSAP     | | Mapping  |<----->| ESRP     |
      | Database |       |          | |          | |
         |          |<-+
      +----------+       +----------+  |
         +-------------------^-------+
                             |
                              ^        | (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 2: Architectural Overview

   Note: Figure 2 does not indicate who runs the ESRP or the mapping
   database.  There are different options available.

5.1.  End Host     |
                        +----------+

                            Figure 1: Overview

   It is important Profile

5.1.1.  LoST Server Discovery

   The end host MAY attempt to note that use [RFC5222] to discover a single ESRP may also offer it's
   service LoST server.
   If that attempt fails, the end host SHOULD attempt to several ISPs.

6.  NAA considerations for discover the network attachment procedure
   address of IAPs/ISPs

   This section discusses different methods to indicate an emergency
   service request as part of network attachment.  It provides some
   general considerations and recommendations ESRP.

5.1.2.  ESRP Discovery

   The end host only needs an ESRP when location configuration or LoST
   server discovery fails.  If that are not specific to
   the access technology.

   To perform network attachment and get access to is the resources
   provided by an IAP/ISP, case, then the end host uses access technology specific
   network attachment procedures, including MUST
   use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option
   for example network
   detection and selection, authentication, Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6)
   and authorization.  For
   initial network attachment / or the "Dynamic Host Configuration Protocol (DHCPv6) Options
   for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover
   the address of an emergency service requester, ESRP.  This SIP proxy located in the
   method of how ISP network
   will be used as the ESRP for routing emergency indication calls.  There is given no
   need to discovery a separate SIP proxy with specific emergency call
   functionality since the IAP/ISP internal procedure for emergency call
   processing is subject of ISP internal operation.

5.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
   specific to not successful, then the access technology.  However, a number of general
   approaches can be identified:

   - Link layer emergency indication: The end host provides an
   indication, e.g. MUST attempt to
   discover an emergency parameter or flag, as part of ESRP, which would assist the link
   layer signaling for initial network attachment.  Examples include an
   emergency bit signalled end host in providing the IEEE 802.16-2009 wireless link.
   signalling allows an IEEE 802.1X
   location to occur without exchanging
   cryptogrpahic keys

   - Higher-layer emergency indication: Typically emergency indication
   in access authentication. the PSAP.

   The emergency caller's SIP UA in the end host provides MUST attach available location information
   in a PIDF-LO [RFC4119] when making an indication as part of the access authentication exchanges.  EAP
   based authentication is of particular relevance here. [nwgstg3].

6.1.  Link layer emergency indication

   In general, link layer call.  When
   constructing the PIDF-LO the guidelines in PIDF-LO profile [RFC5491]
   MUST be followed.  For civic location information the format defined
   in [RFC5139] MUST be supported.

5.1.4.  Emergency Call Identification

   To determine which calls are emergency indications provide good integration calls, some entity needs to
   map a user entered dialstring into this URN scheme.  A user may
   "dial" 1-1-2, but the actual network access procedure regarding call would be sent to urn:service:sos.  This
   mapping SHOULD be performed at the enabling of
   means endpoint device.

   End hosts MUST use the Service URN mechanism [RFC5031] to recognize and prioritize an mark calls
   as emergency service request from
   an end host at a very early stage of 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 network attachment
   procedure.  However, support ESRP in end hosts the ISPs network
   knows the visited emergency dial strings.

5.1.5.  SIP Emergency Call Signaling

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

   The initial SIP signaling method is an INVITE.  The SIP INVITE
   request MUST be
   considered constructed according to be commonly available.

   No general recommendations are given 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.

5.1.6.  Media

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

5.1.7.  Testing

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

5.2.  IAP/ISP Profile

5.2.1.  ESRP Discovery

   An ISP hosting an ESRP MUST implement the following reasons:

   - Dependency on the specific access technology.

   - Dependency on the specific access network architecture.  Access
   authorization and policy decisions typically happen at a different
   layers server side part of the protocol stack
   "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for
   Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and in different entities than those
   terminating /
   or the link-layer signaling.  As a result, link layer
   indications need to be distributed "Dynamic Host Configuration Protocol (DHCPv6) Options for
   Session Initiation Protocol (SIP) Servers" [RFC3319].

5.2.2.  Location Determination and translated between Location Configuration

   When receiving an INVITE message the
   different involved protocol layers and entities.  Appropriate methods following steps are specific to the actual architecture of done:
   1.  If the IAP/ISP network.

6.2.  Higher-layer emergency indication

   This section focuses on emergency indications based on authentication
   and authorization in EAP-based network access.

   An advantage INVITE message does not include location information the
       ESRP-registrar MUST use HELD identity
       [I-D.ietf-geopriv-held-identity-extensions] to obtain the
       location of combining emergency indications with the actual
   network attachment procedure performing authentication device as both a location value and
   authorization is reference.
       In order to contact the fact that LIS the emergency indication can directly
   be taken into account in ESRP-registrar SHOULD determine
       the authentication and authorization server
   that owns LIS address using the policy mechanism described in
       [I-D.thomson-geopriv-res-gw-lis-discovery].  The ESRP-registrar
       MAY use other methods for granting access to LIS determination where available.
   2.  If the network resources.
   As INVITE message contains a result, there is no direct dependency on the access network
   architecture that otherwise would need to take care of merging link-
   layer indications into location URI then the AA and policy decision process.

   EAP signaling happens at a relatively early stage of network
   attachment, ESRP-
       registrar MUST dereference it so that it is likely has a location available
       to match most requirements for
   prioritization of route the impending emergency signaling.  However, it does not cover
   early stages of link layer activity in call.  The ESRP-registrar MAY
       validate the network attachment
   process.  Possible conflicts may arise e.g. LIS address in case the location URI with that of MAC-based
   filtering in entities terminating the link-layer signaling in LIS
       serving the network (like a base station).  In normal operation, EAP related
   information will only be recognized in from which the NAS.  Any entity residing
   between end host and NAS should not be expected to understand/parse
   EAP messages. INVITE message originated.
   3.  The following potential methods to provide emergency indications in
   combination with EAP-based network attachment, are recognized:

   1) NAI-based emergency indication:

   An emergency indication can be given INVITE message contains location information by forming a value.  Any
       actions performed by the ESRP-registrar to valid this information
       are specific NAI that
   is used as to the identity in EAP based authentication for network
   entry.  Methods include:

   1.a) NAI Decoration: NAI decoration is commonly used jurisdiction in routing EAP
   responses within which the IAP/ISP AAA infrastructure.  Additional
   decoration can be used ESRP operates and
       are out of the scope of this document.

5.3.  ESRP Profile

5.3.1.  Emergency Call Routing

   The ESRP must route the emergency call to add an indication that the network
   attachment attempt is meant PSAP responsible for accessing emergency services.
   Potential advantages
   the physical location of such approach include that it requires only
   minimal realization effort compared to link-layer indications with
   good integration into the authentication and authorization
   procedures.  The same procedure can be used end host.  However, a standardized
   approach for all NAA determining the correct PSAP based on a given location
   is useful but not mandatory.

   For cases (both
   unauthenticated and unauthorized) as well as for normal attachment
   with where a valid subscription.  A potential disadvantage standardized protocol is that such EAP
   decoration used LoST [RFC5222] is not globally defined across all different access
   technologies.

   1.b) a
   suitable mechanism.

5.3.2.  Emergency NAI: Call Identification

   The NAI comes with a realm or username part
   indicating ESRP MUST understand the Service URN mechanism [RFC5031] (i.e.,
   the 'urn:service:sos' tree) and additionally the national emergency (e.g. 'emergency@emergency.com').  An advantage
   dial strings.  The ESRP SHOULD perform a mapping of this method for NAA cases is that no new requirements national
   emergency dial strings to Service URNs to simplify processing at
   PSAPs.

5.3.3.  SIP Emergency Call Signaling

   SIP signaling capabilities [RFC3261] are put on mandated for the involved signaling procedures.  Only ESRP.  The
   ESRP MUST process the identity used for
   network entry is impacted.  Potential disadvantages include that
   different methods messages sent by the client, according to indicate emergency for NAA cases and standard
   emergency network attachments may
   Section 5.1.5.  Furthermore, the ESRP MUST be required.  Also, modifying able to add a reference
   to location information, as described in SIP Location Conveyance
   [I-D.ietf-sipcore-location-conveyance], before forwarding the
   NAI itself (the username@realm part) may conflict with network
   selection and network entry procedures, depending on call to
   the actual
   access network.

   2) Emergency EAP method

   An emergency indication can PSAP.  The ISP MUST be given by using prepared to receive incoming dereferencing
   requests to resolve the reference to the location information.

5.3.4.  Location Retrieval

   The ESRP acts a dedicated EAP method
   that is reserved for emergency network attachment only.

   2.a) Existing EAP method location recipient and the usage of HELD [RFC5985]
   with new type: An existing EAP method the identity extensions
   [I-D.ietf-geopriv-held-identity-extensions] may be
   used.  EAP methods themselves typically do not support emergency
   indication.  One option a possible choice.
   The ESRP would be to pick thereby act as a common EAP method like
   EAP-TLS HELD client and allocate a new method type for the same method that is
   exclusively reserved to emergency use.  Such EAP method should be
   chosen in a way that corresponding LIS
   at the same method can support NAA cases as well as
   standard emergency network attachment.

   2.b) Existing EAP method: Same ISP as 2a), but without assigning a new
   EAP method type for emergency.  In this case some implicit indication
   must 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.  For example, in cases where EAP-TLS is used in network
   attachment in combination with client certificates, as input to LoST
   to obtain the absence PSAP URI.

6.  Lower Layer Considerations for NAA Case

   Some radio networks have added support for unauthenticated emergency
   access, some other type of a
   client certificate could be interpreted by networks advertise these capabilities
   using layer beacons.  The end host learns about these unauthenticated
   emergency services capabilities either from the network as a request
   for link layer type or
   from advertisement.

   This section discusses different methods to indicate an emergency
   service request as part of network attachment.

   2.c) Emergency EAP method: A new EAP method could be defined  It provides some
   general considerations and recommendations that is
   specifically designed for emergency network entry in NAA cases.  Most
   likely, such EAP method would are not be usable for standard emergency
   network attachment with an existing subscription.  Such dedicated
   emergency EAP method should be key-generating in compliance with
   RFC3748 specific to enable
   the regular air interface security methods even in
   unauthenticated operation.

6.3.  Securing network attachment in NAA cases

   For access technology.

   To perform network attachment in NAA cases, it may make sense and get access to secure the
   link-layer connection between the device and resources
   provided by an IAP/ISP, the IAP/ISP.  This
   especially holds for wireless end host uses access with examples being based
   access.  The latter even mandates secured communication across the
   wireless link for all IAP/ISP networks based on [nwgstg3].

   Therefore, for technology specific
   network attachment that is by default based on EAP
   authentication it is desirable also procedures, including for NAA example network
   detection and selection, authentication, and authorization.  For
   initial network attachment to use
   a key-generating EAP method (that provides of an MSK key to emergency service requester, the
   authenticator
   method of how the emergency indication is given to bootstrap further key derivation for protecting the
   wireless link).

   The following approaches IAP/ISP is
   specific to match the above access technology.  However, a number of general
   approaches can be identified:

   1) Server-only authentication:

   Link layer emergency indication:  The device end host provides an
      indication, e.g. an emergency parameter or flag, as part of the
      link layer signaling for initial network attachment.  Examples
      include an emergency service
   requester performs bit signalled in the IEEE 802.16-2009
      wireless link. signalling allows an EAP method with IEEE 802.1X to occur without
      exchanging cryptogrpahic keys.

   Higher-layer emergency indication:  Typically emergency indication in
      access authentication.  The emergency caller's end host provides
      an indication as part of the IAP/ISP access authentication exchanges.  EAP server that
   performs server
      based authentication only.  An example for this is EAP-TLS.
   This provides a certain level of assurance about the IAP/ISP to the
   device user.  It requires the device to be provisioned with
   appropriate trusted root certificates to be able to verify the server
   certificate of particular relevance here. [nwgstg3].

6.1.  Link Layer Emergency Indication

   In general, link layer emergency indications provide good integration
   into the EAP server (unless this step is explicitly skipped
   in actual network access procedure regarding the device in case enabling of
   means to recognize and prioritize an emergency service request).

   2) Null authentication: an EAP method is performed.  However, no
   credentials specific to either the server or the device or
   subscription are used as part of the authentication exchange.  An
   example for this would be request from
   an EAP-TLS exchange with using the
   TLS_DH_anon (anonymous) ciphersuite.  Alternatively, end host at a publicly
   available static key very early stage of the network attachment
   procedure.  However, support in end hosts for emergency access could such methods cannot be used.  In the
   latter case, the device would need
   considered to be provisioned with commonly available.

   No general recommendations are given in the
   appropriate emergency key for scope of this memo due to
   the IAP/ISP in advance.

   3) Device authentication: This case extends following reasons:
   o  Dependency on the server-only
   authentication case.  If specific access technology.
   o  Dependency on the device is configured with specific access network architecture.  Access
      authorization and policy decisions typically happen at a device
   certificate different
      layers of the protocol stack and in different entities than those
      terminating the IAP/ISP EAP server can rely on link-layer signaling.  As a trusted root
   allowing the EAP server result, link layer
      indications need to verify the device certificate, at least be distributed and translated between the device identity (e.g.
      different involved protocol layers and entities.  Appropriate
      methods are specific to the MAC address) can be authenticated by actual architecture of the IAP/ISP
      network.

6.2.  Higher-Layer Emergency Indication

   This section focuses on emergency indications based on authentication
   and authorization in NAA cases. EAP-based network access.

   An example for this are WiMAX devices that
   are shipped with device certificates issued under the global WiMAX
   device public-key infrastructure.  To perform unauthenticated advantage of combining emergency calls, if allowed by indications with the IAP/ISP, such devices perform EAP-
   TLS based actual
   network attachment with client procedure performing authentication based on and
   authorization is the fact that the emergency indication can directly
   be taken into account in the authentication and authorization server
   that owns the
   device certificate.

7.  Profiles
7.1.  End Host Profile

7.1.1.  LoST Server Discovery

   The end host MAY attempt to use [I-D.ietf-ecrit-lost] policy for granting access to discover the network resources.
   As a
   LoST server.  If that attempt fails, result, there is no direct dependency on the end host SHOULD attempt access network
   architecture that otherwise would need to
   discover take care of merging link-
   layer indications into the address AA and policy decision process.

   EAP signaling happens at a relatively early stage of an ESRP.

7.1.2.  ESRP Discovery

   The end host only needs an ESRP when location configuration or LoST
   server discovery fails.  If that network
   attachment, so it is likely to match most requirements for
   prioritization of emergency signaling.  However, it does not cover
   early stages of link layer activity in the case, then network attachment
   process.  Possible conflicts may arise e.g. in case of MAC-based
   filtering in entities terminating the link-layer signaling in the
   network (like a base station).  In normal operation, EAP related
   information will only be recognized in the NAS.  Any entity residing
   between 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] NAS should not be expected to discover understand/parse
   EAP messages.

   The following potential methods to provide emergency indications in
   combination with EAP-based network attachment, are recognized:

   1.  NAI-based emergency indication:

       An emergency indication can be given by forming a specific NAI
       that is used as the address of an ESRP.  This SIP proxy located identity in EAP based authentication for
       network entry.  Methods include:

   2.
       1.a) NAI Decoration:

          NAI decoration is commonly used in routing EAP responses
          within the ISP network
   will IAP/ISP AAA infrastructure.  Additional decoration
          can be used as to add an indication that the ESRP network attachment
          attempt is meant for routing accessing emergency calls.  There is no
   need services.  Potential
          advantages of such approach include that it requires only
          minimal realization effort compared to discovery a separate SIP proxy link-layer indications
          with specific emergency call
   functionality since good integration into the internal authentication and
          authorization procedures.  The same procedure can be used for emergency call
   processing is subject of ISP internal operation.

7.1.3.  Location Determination
          all NAA cases (both unauthenticated and Location Configuration

   The end host SHOULD attempt to use the supported LCPs to configure
   its location.  If no LCP unauthorized) as well
          as for normal attachment with a valid subscription.  A
          potential disadvantage is supported in the end host or the location
   configuration that such EAP decoration 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.
          globally defined across all different access technologies.

       1.b) Emergency NAI:

          The SIP UA in the end host SHOULD attach the location information in NAI comes with a PIDF-LO [RFC4119] when making an realm or username part indicating
          emergency call.  When constructing (e.g. 'emergency@emergency.com').  An advantage of
          this method for NAA cases is that no new requirements are put
          on the PIDF-LO involved signaling procedures.  Only the guidelines in PIDF-LO profile
   [I-D.ietf-geopriv-pdif-lo-profile] MUST identity used
          for network entry is impacted.  Potential disadvantages
          include that different methods to indicate emergency for NAA
          cases and standard emergency network attachments may be followed.  For civic
   location information
          required.  Also, modifying the format defined in [RFC5139] MUST be
   supported.

7.1.4. NAI itself (the username@realm
          part) may conflict with network selection and network entry
          procedures, depending on the actual access network.
   3.  Emergency Call Identification

   To determine which calls are EAP method

       An emergency calls, some entity needs to
   map indication can be given by using a user entered dialstring into this URN scheme.  A user dedicated EAP
       method that is reserved for emergency network attachment only.
       2.a) Existing EAP method with New Method Type:

          An existing EAP method may
   "dial" 1-1-2, but the call be used.  EAP methods themselves
          typically do not support emergency indication.  One option
          would be sent to urn:service:sos.  This
   mapping SHOULD be performed at the endpoint device.

   End hosts MUST use pick a common EAP method like EAP-TLS and allocate
          a new method type for the Service URN mechanism [RFC5031] same method that is exclusively
          reserved to mark calls emergency use.  Such EAP method should be chosen
          in a way that the same method can support NAA cases as well as
          standard emergency calls network attachment.

       2.b) Existing EAP Method:

          Same as 2a), but without assigning a new EAP method type for their home emergency dial string (if known).
          emergency.  In this case some implicit indication must be
          used.  For visited emergency dial string the translation into the Service
   URN mechanism example, in cases where EAP-TLS is not mandatory since the ESRP used in the ISPs network
   knows
          attachment in combination with client certificates, the visited
          absence of a client certificate could be interpreted by the
          network as a request for emergency dial strings.

7.1.5.  SIP network attachment.

       2.c) Emergency Call Signaling

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

   The initial SIP signaling EAP Method:

          A new EAP method could be defined that is specifically
          designed for emergency network entry in NAA cases.  Most
          likely, such EAP method would not be usable for standard
          emergency network attachment with an INVITE.  The SIP INVITE
   request MUST existing subscription.
          Such dedicated emergency EAP method should be constructed according key-generating
          in compliance with RFC3748 to enable the requirements regular air interface
          security methods even in Section
   9.2 [I-D.ietf-ecrit-phonebcp].

   Regarding callback behavior SIP UAs MUST have a globally routable URI unauthenticated operation.

6.3.  Securing Network Attachment in a Contact: header.

7.1.6.  Media

   End points MUST comply with NAA Cases

   For network attachment in NAA cases, it may make sense to secure the media requirements
   link-layer connection between the device and the IAP/ISP.  This
   especially holds for end points
   placing an emergency call found in Section 14 of
   [I-D.ietf-ecrit-phonebcp].

7.1.7.  Testing wireless access with examples being based
   access.  The description in Section 15 of [I-D.ietf-ecrit-phonebcp] latter even mandates secured communication across the
   wireless link for all IAP/ISP networks based on [nwgstg3].

   Therefore, for network attachment that is fully
   applicable by default based on EAP
   authentication it is desirable also for NAA network attachment to this document.

7.2.  IAP/ISP Profile

7.2.1.  ESRP Discovery

   An ISP hosting use
   a key-generating EAP method (that provides 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 MSK key to the "Dynamic Host Configuration Protocol (DHCPv6) Options
   authenticator to bootstrap further key derivation for
   Session Initiation Protocol (SIP) Servers" [RFC3319].

7.2.2.  Location Determination and Location Configuration protecting the
   wireless link).

   The ISP not hosting an ESRP MUST support at least one widely used
   LCP. following approaches to match the above can be identified:

   1) Server-only Authentication:

      The ISP hosting an ESRP MUST perform device of the neccesary steps to
   determine emergency service requester performs an EAP
      method with the location IAP/ISP EAP server that performs server
      authentication only.  An example for this is EAP-TLS.  This
      provides a certain level of assurance about the end host. IAP/ISP to the
      device user.  It is not necessary requires the device to
   standardize a specific mechanism.

   The role be provisioned with
      appropriate trusted root certificates to be able to verify the
      server certificate of the ISP EAP server (unless this step is
      explicitly skipped in the device in case of an emergency service
      request).

   2) Null Authentication:

      an EAP method is performed.  However, no credentials specific to operate
      either the LIS.  The usage server or the device or subscription are used as part
      of HELD
   [I-D.ietf-geopriv-http-location-delivery] with the identity
   extensions [I-D.ietf-geopriv-held-identity-extensions] may authentication exchange.  An example for this would be an
      EAP-TLS exchange with using the TLS_DH_anon (anonymous)
      ciphersuite.  Alternatively, a
   possible choice.  It might be necessary publicly available static key for
      emergency access could be used.  In the ISP to talk latter case, the device
      would need to be provisioned with the
   IAP appropriate emergency key
      for the IAP/ISP in order to determine advance.

   3) Device Authentication:

      This case extends the location of server-only authentication case.  If the end host.  The work on
   LIS-to-LIS communication may be relevant, see
   [I-D.winterbottom-geopriv-lis2lis-req].

7.3.  ESRP Profile

7.3.1.  Emergency Call Routing

   The ESRP must route
      device is configured with a device certificate and the IAP/ISP EAP
      server can rely on a trusted root allowing the emergency call EAP server to
      verify the PSAP responsible for device certificate, at least the physical location of device identity (e.g.,
      the end host.  However, a standardized
   approach MAC address) can be authenticated by the IAP/ISP in NAA cases.
      An example for determining this are WiMAX devices that are shipped with device
      certificates issued under the correct PSAP global WiMAX device public-key
      infrastructure.  To perform unauthenticated emergency calls, if
      allowed by the IAP/ISP, such devices perform EAP-TLS based network
      attachment with client authentication 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.

7.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. device
      certificate.

7.  Security Considerations

   The ESRP SHOULD perform security threats discussed in [RFC5069] are applicable to this
   document.

   There are a mapping couple of national new vulnerabilities raised with unauthenticated
   emergency dial strings to Service URNs to simplify processing at
   PSAPs.

7.3.3.  SIP Emergency Call Signaling

   SIP signaling capabilities [RFC3261] are mandated for the ESRP.  The
   ESRP MUST process services in NASP/NAA cases since the messages sent by PSAP operator will
   typically not possess any identity information about the client, according to
   Section 7.1.5.  Furthermore, emergency
   call via the ESRP MUST be able signaling path itself.  In countries where this
   functionality is used for GSM networks today this has lead to add a reference
   significant amount of misuse.

   In the context of NAA, the IAP and the ISP will probably want to location information, as described in SIP Location Conveyance
   [I-D.ietf-sip-location-conveyance], before forwarding make
   sure that the claimed emergency caller indeed performs an emergency
   call to rather than using the
   PSAP.  The ISP MUST be prepared to receive incoming dereferencing
   requests to resolve network for other purposes, and thereby
   acting fraudulent by skipping any authentication, authorization and
   accounting procedures.  By restricting access of the reference unauthenticated
   emergency caller to the location information.

7.3.4.  Location Retrieval

   The ESRP acts a location recipient LoST server and the usage of HELD
   [I-D.ietf-geopriv-http-location-delivery] with the identity
   extensions [I-D.ietf-geopriv-held-identity-extensions] may PSAP URI, traffic can be a
   possible choice.
   restricted only to emergency calls.  This can be accomplished with
   traffic separation.  The ESRP would thereby act as a HELD client details, however, e.g. for using filtering,
   depend on the deployed ISP architecture and are beyond the
   corresponding LIS at scope of
   this document.

   We only 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 HELD server.

   The ESRP needs LoST server itself.  (It may need to obtain enough information translate the domain
   names returned to route IP addresses and hope that the call.  The
   ESRP itself, however, does resolution captures
   all possible DNS responses.)  Since the media destination addresses
   are not necessarily need predictable, the ISP also has to process location
   information obtained via HELD since provide a SIP outbound proxy
   so that it may be used as input can determine the media addresses and add those to the
   filter list.

   For the ZBP case the additional aspect of fraud has to be considered.
   Unless the emergency call traverses a PSTN gateway or the ASP charges
   for IP-to-IP calls, there is little potential for fraud.  If the ASP
   also operates the LoST server, the outbound proxy MAY restrict
   outbound calls to obtain the PSAP URI.

8.  Security Considerations

   The security threats discussed in [RFC5069] are applicable SIP URIs returned by the LoST server.  It is
   NOT RECOMMENDED to this
   document.  A rely on a fixed list of SIP URIs, as that list may
   change.

   Finally, a number of security vulnerabilities discussed in
   [I-D.ietf-geopriv-arch] around faked location information are less
   problematic in this case the context of unauthenticated emergency 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.

9.

8.  Acknowledgments

   Section 6

   Parts of this document is are 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.

10.

9.  IANA Considerations

   This document does not require actions by IANA.

11.

10.  References

11.1.

10.1.  Normative References

   [I-D.ietf-sip-location-conveyance]

   [I-D.ietf-sipcore-location-conveyance]
              Polk, J. and B. J., Rosen, B., and J. Peterson, "Location Conveyance
              for the Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-13
              draft-ietf-sipcore-location-conveyance-03 (work in
              progress),
              March 2009. July 2010.

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

   [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              PIDF-LO
              Presence Information Data Format Location Object (PIDF-LO)
              Usage Clarification, Considerations Considerations, and Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
              (work in progress), November 2008.
              RFC 5491, March 2009.

   [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-15 (work in progress),
              July 2010.

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

11.2.

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]

   [RFC5687]  Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Protocol: Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
              progress), July 2009. RFC 5687, March 2010.

   [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-11 (work in
              progress), July 2010.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J.,

   [I-D.thomson-geopriv-res-gw-lis-discovery]
              Thomson, M., M. and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-16 R. Bellis, "Location Information Server
              (LIS) Discovery using IP address and Reverse DNS",
              draft-thomson-geopriv-res-gw-lis-discovery-04 (work in
              progress), August 2009. September 2010.

   [RFC5985]  Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
              RFC 5985, September 2010.

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

   [I-D.ietf-geopriv-held-identity-extensions]
              Winterbottom, J., Thomson, M., Tschofenig, H., and R.
              Barnes, "Use of Device Identity in HTTP-Enabled Location
              Delivery (HELD)",
              draft-ietf-geopriv-held-identity-extensions-04
              draft-ietf-geopriv-held-identity-extensions-05 (work in
              progress), June October 2010.

   [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.ietf-geopriv-arch]
              Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
              Tschofenig, H., and H. Schulzrinne, "An Architecture for
              Location and Location Privacy in Internet Applications",
              draft-ietf-geopriv-arch-02
              draft-ietf-geopriv-arch-03 (work in progress), May
              October 2010.

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

   [nwgstg3]  "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network
              Architecture Stage-3
              http://www.wimaxforum.org/sites/wimaxforum.org/files/ tech
              nical_document/2009/09/
              DRAFT-T33-001-R015v01-O_Network-Stage3-Base.pdf",
              September 2009.

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
   Research in Motion UK Ltd
   200 Bath Road
   Slough, Berks  SL1 3XE
   UK

   Phone: +44 1753 667099
   Email: smccann@rim.com
   URI:   http://www.rim.com

   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
   Dirk Kroeselberg
   Nokia Siemens Networks
   St.-Martin-Str. 76
   Munich  81541
   Germany

   Phone: +49 (89) 515933019
   Email: Dirk.Kroeselberg@nsn.com