Emergency Communication Services over Wi-Fi Access Networks
draft-gundavelli-dispatch-e911-wifi-02
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Sri Gundavelli , Mark Grayson | ||
| Last updated | 2024-01-11 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gundavelli-dispatch-e911-wifi-02
DISPATCH S. Gundavelli
Internet-Draft M. Grayson
Intended status: Standards Track Cisco
Expires: 14 July 2024 11 January 2024
Emergency Communication Services over Wi-Fi Access Networks
draft-gundavelli-dispatch-e911-wifi-02
Abstract
This document introduces an approach to enable emergency services
over Wi-Fi access networks. These services encompass emergency
services such as 911 in North America, 112 in the European Union, and
equivalent emergency services in other regulatory domains. The
proposed approach aims to provide a comprehensive solution for
supporting emergency communication across different regions and
regulatory frameworks.
Leveraging the legal framework and infrastructure of the OpenRoaming
federation, this proposal aims to extend emergency calling
capabilities to the vast number of OpenRoaming Wi-Fi hotspots that
have already been deployed.
The approach addresses critical challenges related to emergency
calling, including discovery and authentication procedures for
accessing networks that support emergency services, emergency access
credentials, the configuration of emergency voice services, accurate
location determination of the emergency caller, and call spofing.
By providing a comprehensive solution, this proposal ensures that
emergency communication services can be seamlessly and effectively
supported within the IEEE 802.11-based Wi-Fi ecosystem leveraging
Passpoint Profiles.
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 https://datatracker.ietf.org/drafts/current/.
Gundavelli & Grayson Expires 14 July 2024 [Page 1]
Internet-Draft Emergency Communication Services January 2024
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 14 July 2024.
Copyright Notice
Copyright (c) 2024 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Emergency Service Architectures - Current Art . . . . . . . . 5
3.1. IETF Protocol Support . . . . . . . . . . . . . . . . . . 5
3.2. NG911 and NG112 Emergency Systems . . . . . . . . . . . . 6
3.3. 3GPP Emergency Service Architecture . . . . . . . . . . . 7
4. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Scenario Description . . . . . . . . . . . . . . . . . . 8
4.2. Technical Architecture . . . . . . . . . . . . . . . . . 9
5. Key Service Requirements . . . . . . . . . . . . . . . . . . 11
6. Access Network Location . . . . . . . . . . . . . . . . . . . 12
7. WLAN Network Identification and Selection . . . . . . . . . . 12
8. Legal and Regulatory Requirements . . . . . . . . . . . . . . 13
9. Authentication on the emergency RCOI WLAN . . . . . . . . . . 13
10. Authentication using the sos.fcc-authorized.org realm . . . . 13
11. Emergency CSCF operation for end-users using
sos.fcc-authorized.org credentials . . . . . . . . . . . 14
12. Emergency calling by OpenRoaming subscribers on MNOs . . . . 14
13. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Gundavelli & Grayson Expires 14 July 2024 [Page 2]
Internet-Draft Emergency Communication Services January 2024
17.1. Normative References . . . . . . . . . . . . . . . . . . 19
17.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
The Federal Communications Commission's (FCC) Communications
Security, Reliability, and Interoperability Council (CSRIC) have
completed a report that is currently under FCC review. The report
focuses on the utilization of Wi-Fi technology for accessing
emergency 911 services in areas without mobile coverage. It provides
an overview of non-proprietary standards capable of facilitating 911
services over Wi-Fi networks based on the IEEE 802.11 technology.
Additionally, the report highlights the potential need for legal and
regulatory adjustments to address concerns related to liability,
privacy, and security when enabling public access to 911 services via
Wi-Fi.
The study looked at the technical feasibility and cost of:
* making telecommunications service provider-owned Wi-Fi access
points, and other communications technologies operating on
unlicensed spectrum, available to the general public for access to
9-1-1 services, without requiring any login credentials, during
times of emergency when mobile service is unavailable;
* the provision by non-telecommunications service provider-owned Wi-
Fi access points of public access to 9-1-1 services during times
of emergency when mobile service is unavailable; and
* alternative means of providing the public with access to 9-1-1
services during times of emergency when mobile service is
unavailable."
These initiatives showcase the dedication of regulatory entities to
enhance access to emergency services through Wi-Fi-based networks.
It is important to note that these efforts are not limited to any one
specific regulatory domain but represent a widespread trend.
This document introduces an approach that aligns with ongoing efforts
to enhance emergency communication services over unlicensed Wi-Fi
access networks. It proposes utilizing the OpenRoaming federation
[I-D.tomas-openroaming] of Wi-Fi access providers and Identity
Providers to facilitate the provision of emergency services.
Gundavelli & Grayson Expires 14 July 2024 [Page 3]
Internet-Draft Emergency Communication Services January 2024
By leveraging a pre-configured emergency passpoint profile, any Wi-
Fi-enabled device situated within the coverage area of an OpenRoaming
hotspot that supports emergency services will have the capability to
access the available emergency communication services provided in
that region.
2. Conventions and Terminology
2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology
All the terms used in this document are to be interpreted as defined
in the IETF and 3GPP specifications. For convenience, the
definitions for some of the terms are provided below.
OpenRoaming (OR)
A federation that provides the framework for connecting
unprecedented footprint of millions of Wi-Fi hotspots with
identity providers.
Identity Provider (IDP)
An entity that manages identity credentials and policies for
devices and provides authentications services.
Access Network Provider (ANP)
An entity providing internet connectivity services.
Passpoint Profile
Passpoint is a Wi-Fi Alliance (WFA) protocol that enables mobile
devices to discover and authenticate to Wi-Fi hotspots that
provide internet access. Profile includes the user's credentials
and the access network identifiers.
Roaming Consortium Identifier (RCOI)
It is a 3-octet, or a 5-octet value carried in the 802.11 beacon
information element (IE). It is also sent in the ANQP messages.
RCOI identifies the groups or identity providers that are
supported by the network.
Gundavelli & Grayson Expires 14 July 2024 [Page 4]
Internet-Draft Emergency Communication Services January 2024
Connectivity Location Function (CLF)
It maintains mappings between the endpoint's dynamically assigned
IP address and its physical location. An enhanced CLF maintains
the mapping between the devices' access point identifier (BSSID)
and the physical location.
Public Safety Answering Point (PSAP)
A PSAP is a facility where emergency calls are received under the
responsibility of a public authority.
Route Determination Function (RDF)
It resolves a physical location, either a civic address or a geo-
spatial address to the serving PSAP.
P-CSCF
Proxy Call Session Control Function. P-CSCF is a specific 3GPP
function ([TS23501]) defined in their IMS architecture. It
largely a 3GPP variant of the IETF SIP Proxy function [RFC3261].
E-CSCF
Enhanced Call Session Control Function. It takes the requests
from P-CSCF (Proxy CSCF) and routes the emergency sessions to the
PSAP based on CLF and RDF queries.
3. Emergency Service Architectures - Current Art
3.1. IETF Protocol Support
The IETF has made significant contributions to the development of
emergency architectures, which serve as the foundation for Next
Generation 911 and 112 systems. These efforts encompass a wide range
of protocols and cover essential aspects, including location
determination and other relevant elements. The following key
specifications highlight these contributions: [RFC4119], [RFC4676],
[RFC5222], [RFC5985], [RFC6225], [RFC6442], [RFC6443] [RFC6881],
[RFC7852], and [RFC8876],
Gundavelli & Grayson Expires 14 July 2024 [Page 5]
Internet-Draft Emergency Communication Services January 2024
However, it is worth noting that a substantial portion of the work
conducted by the IETF predates the current industry focus on roaming
in Wi-Fi networks using Passpoint profiles and identity federation
rameworks, as well as the infrastructure established by the
OpenRoaming federation. There is inherent value in standardizing
emergency communication approaches that align with these newer
industry developments around Wi-Fi roaming.
The primary objective of these efforts is to enable individuals with
Wi-Fi devices within the coverage area of an OpenRoaming hotspot to
connect to the network without requiring specific access credentials.
This allows them to make emergency calls seamlessly and without any
barriers. This can save lives!
3.2. NG911 and NG112 Emergency Systems
Next Generation 911 (NG911) is the new emergency communication system
designed to enhance the effectiveness and efficiency of emergency
services. NG911 builds upon the existing 911 emergency response
infrastructure by integrating newer capabilities.
The implementation of the NG911 architecture is planned to occur in
multiple phases. The first phase focuses on enhancing the existing
legacy 911 architecture. Following this, a transitional phase will
be implemented to gradually transition to the full-fledged NG911
system. Finally, the End State NG911 Service architecture will be
established to provide the ultimate NG911 capabilities.
NG911 leverages IP-based networks to transmit emergency
communications, enabling seamless integration with various digital
platforms and devices. It enables individuals to contact emergency
services not only through traditional phone calls but also through
text messages, multimedia messages, and even real-time video
streaming. This provides greater flexibility for individuals with
diverse communication preferences or accessibility needs.
One of the significant advantages of NG911 is the ability to receive
more detailed location information from callers. Traditional 911
systems rely on the location of the calling device or the cell tower
used for the call, which can sometimes result in imprecise location
data. NG911 leverages Global Navigation Satellite Systems (GNSS) to
obtain more accurate and reliable location information, allowing
emergency services to respond more swiftly and precisely.
NG911 architecture is based on IETF standards. The SIP UA which is
authenticated to the P-CSCF, creates a SIP INVITE that includes
location information in the form of a Presence Information Data
Format Location Object (PIDF-LO) in the body of the message. The
Gundavelli & Grayson Expires 14 July 2024 [Page 6]
Internet-Draft Emergency Communication Services January 2024
P-CSCF passes the SIP INVITE to the E-CSCF. The E-CSCF passes the
SIP INVITE message to the LRF to obtain location and routing
information for the emergency call. LRF will use the Location to
Service Translation (LoST) protocol [RFC5222] to query the RDF. The
RDF will determine routing based on the routing location
NG112 is the new emergency communication system designed to improve
emergency services by integratung modern technologies and
capabilities. It is a European initiative that aims to enhance the
existing emergency response infrastructure, building upon the legacy
of the widely recognized emergency number, 112. NG112 largely
follows the NG911 architecture and is based on IETF standards.
3.3. 3GPP Emergency Service Architecture
The 3rd Generation Partnership Project (3GPP) has developed an
Emergency Service architecture that enables effective and reliable
emergency communication services within cellular networks. This
architecture encompasses various components and protocols designed to
ensure prompt emergency assistance.
The essential component of the architecture is the Emergency Services
(ES) functionality, which allows users to dial emergency numbers,
such as 112 or 911, to access emergency services. ES interfaces with
the cellular network infrastructure to establish emergency calls and
deliver them to the appropriate Public Safety Answering Point (PSAP)
or emergency call center.
Additionally, the architecture includes the Location Services (LCS)
system, which enables accurate positioning of emergency callers. LCS
uses various positioning methods, including GPS, and network-based
methods, to determine the caller's location and transmit it to the
PSAP for effective emergency response.
The 3GPP Emergency Service architecture also incorporates support for
multimedia services, such as text messages, images, and videos,
enabling individuals to provide additional information to emergency
services during critical situations.
Overall, the 3GPP Emergency Service architecture ensures that
cellular networks have the necessary capabilities to handle emergency
calls, deliver accurate location information, and support multimedia
communication for effective emergency response and public safety.
Gundavelli & Grayson Expires 14 July 2024 [Page 7]
Internet-Draft Emergency Communication Services January 2024
4. Proposed Approach
WBA's OpenRoaming is a roaming federation service of Access Network
Providers (ANPs) and Identity Providers (IDPs), enabling an automatic
and secure Wi-Fi experience globally. WBA OpenRoaming creates the
framework to seamlessly connect devices to the access networks that
are part of the federation. For further insights into the
architectural specifics of WBA's OpenRoaming, please refer to the
document, [I-D.tomas-openroaming].
ANP-1 --\ _----_ /-- IDP-1
\ Access _( Open )_ Identity /
ANP-2 ---<== Network ---( Roaming )--- Providers <==-- IDP-2
/ Providers (_ _) \
ANP-3 --/ '----' \-- IDP-3
Figure 1: OpenRoaming Federation
The solution presented in this proposal utilizes the legal framework
and core components of the OpenRoaming federation to extend emergency
calling capabilities (e.g. 911/112) to tens of thousands of existing
OpenRoaming hotspots operating on unlicensed Wi-Fi networks. The
following text explains the architectural framework of this approach.
4.1. Scenario Description
* A Wi-Fi-enabled device equipped with a pre-installed emergency
passpoint profile and located within the coverage area of an
OpenRoaming hotspot. The device does not have the access network
credentials for that hotspot, other than the emergency passpoint
profile.
* The hotspot is configured to facilitate emergency communication
services. It advertises the emergency RCOI (Roaming Consortium
Identifier) in the IEEE 802.11 beacon messages.
* When a user dials the emergency calling number designated for
their regulatory domain (such as 911/112), their device initiates
a search for Wi-Fi networks that support emergency services by
comparing the RCOI field of the passpoint profile. Upon finding a
match, temporary access to the network is granted. The user's
location is relayed to the Identity Provider (IDP) by the access
network.
Gundavelli & Grayson Expires 14 July 2024 [Page 8]
Internet-Draft Emergency Communication Services January 2024
* The device obtains the emergency service configuration from the
IDP designated for the emergency realm, and specific to that
locale.
* User makes the emergency call registration. User's location
reported in the call signaling is cross correlated with the
location reported by the access network.
* User's call is routed to the nearest PSAP.
4.2. Technical Architecture
IDP
+===================================+
| IDP: (e.g.)sos.fcc-authorized.org)|
| +---+ +------+ |
| |CLF|--------------|E-CSCF| |
| +---+ CLF Query +------+ |
| | for Location | |---><PSAP>
| +---+ +------+ |
| |AAA| |P-CSCF| |
| +---+ +------+ |
+===================================+
. : .
/|\ : /|\
| : |
_----_ | : |
_( Open )_ | : |
----( Roaming )............: |
(_ _) | : |
'----' | : |
| _-----_ |
(RADIUS Signaling)| _( )_ | (SIP Signaling)
| ( Access )- |
RADIUS Attributes | -(_Network)- | P-Access-Network-Info
(BSSID, Civic-Loc | '-----' | SIP Header (RFC 3455)
/Geo-Loc and SLT)| | | and RFC 7315 Defined
| | | 3GPP Header for carrying
\|/ | | BSSID and/or SLT
. +----+ |
| AP | |
+----+ |
: |
: \|/
+========+
| Device | (Emergency Passpoint Profile)
+========+
Gundavelli & Grayson Expires 14 July 2024 [Page 9]
Internet-Draft Emergency Communication Services January 2024
Figure 2: Technical Architecture
The E-CSCF (Emergency Call Session Control Function) and P-CSCF
(Proxy-Call Session Control Function) are well-defined functions
within the IMS (IP Multimedia Subsystem) architecture as specified by
3GPP. These functions can be utilized for emergency calling
purposes, or alternatively, they can be substituted with an IETF SIP
Proxy [RFC3261], to support the necessary calling services.
There will be a designated Identity Provider (IDP) and designated
emergency calling services for supporting emergency calling service
(e.g., 911/112). The AAA server in the IDP supports the realm for
that region (e.g. "@sos.fcc-authorized.org") and the EMERGENCY-RCOI
policies (i.e., for example an 911/112 specific HotSpot2.0 Roaming
Consortium or RCOI). There will also be dedicated P/E-CSCF (Proxy/
Emergency Call Services Control Function) for supporting emergency
calling services. DNS servers for the realm will be configured to
enable ANPs to dynamically discover the designated IDP's AAA servers.
The devices are pre-configured with a HotSpot2.0/Passpoint profile,
which includes the emergency RCOI, and a common identity, e.g.,
anonymous@sos.fcc-athorized.org. Device eco-systems vendors can pre-
configure this profile into every device at the time of manufacturing
or push an updated profile using established carrier-bundle based
provisioning. This anonymous profile will be common for all devices.
This allows the device to discover Wi-Fi access networks that support
emergency services (e.g. 911/112). Furthermore, the SIP User Agent
in the mobile device will be able to use P/E-CSCF configuration
obtained from the Wi-Fi access network.
Wi-Fi access networks that are part of the OpenRoaming federation and
willing to support emergency communication services will configure
the emergency RCOI on their WLAN equipment. WLAN OEM suppliers can
augment existing OpenRoaming provisioning interfaces with emergency
RCOI settings. These networks allow any devices without access
credentials to connect to the network for emergency calling. The Wi-
Fi access network will recover the realm from the identity and use
DNS system to discover the designated IDP's AAA servers.
OpenRoaming already requires access networks to provide their Civic
Location and/or Geo-spatial coordinates in the IDP signaling
messages. The location information may be manually configured or can
be obtained from a reliable source. The device will also be able to
discover emergency voice services (CSCF) and the related
configuration from the access network or from a cloud entity. This
allows device to be able to use the emergency services when connected
to access networks that are not part of the OpenRoaming federation.
NOTE that this assumes that the device has basic internet
Gundavelli & Grayson Expires 14 July 2024 [Page 10]
Internet-Draft Emergency Communication Services January 2024
connectivity and can initiate emergency calls without requiring
emergency calling support from the access network. The device can
include location elements, obtained either from the access network or
from a cloud function, and include them in the SIP signaling using
the Geolocation header fields defined in RFC 6442. The E-CSCF
function will retrieve the location elements from the signaling
messages from the device.
For supporting the architecture based on this approach, we need the
following updates to the WBA OpenRoaming architecture.
* enhancement to WBA OpenRoaming technical framework to include use
of emergency RCOI.
* enhancements to OpenRoaming templated legal terms for access
network providers on use of emergency RCOI and associated
requirements, e.g., related to use of existing defined RFC 5580
location attributes.
* updates to WBA WRIX offered-service VSA to include new string for
"openroaming-emergency" service definition.
* definition of policies required to be enforced by ANP when filter-
id attribute mirrors the "openroaming-emergency" tag.
5. Key Service Requirements
An emergency call handling service shall be designated to handle Wi-
Fi-enabled emergency calls (e.g. 911/112), along with an IDP function
for the respective realm e.g., "sos.fcc-authorized.org", where an
existing MNO cannot (non-provisioned device or MNO core is
unavailable). This should consider third-party providers such as
IDPaaS/MNO/Voice Service Providers to host these services.
Broadband service providers and HotSpot venue operators shall provide
the Civic-Location and or the Geo-spatial coordinates of the venue,
and the emergency voice service configuration to the device in the IP
address configuration procedures.
Consumer devices should be pre-configured by OEMs or through
established carrier-bundle based provisioning with a HotSpot2.0/
Passpoint profile, including the emergency RCOI and a common identity
such as (e.g.) "anonymous@sos.fcc-authorized.org.".
Gundavelli & Grayson Expires 14 July 2024 [Page 11]
Internet-Draft Emergency Communication Services January 2024
6. Access Network Location
Location of the caller is a key element in the emergency-service
workflow. Emergency response centers must be able to determine the
location of the caller before service is dispatched. A caller may be
too young, frightened or confused to provide the location of
emergency, therefore automatic location determination by PSAP is an
essential requirement.
The device making the emergency call must be able to obtain the Civic
and/or Geo-spatial coordinates for inclusion in SIP Registration
messages. Reliance on GPS is not an option for most indoor
environments.
The WLANs supporting emergency 911 services should be capable of
providing the Civic Location or the Geo-Spatial coordinates of the
caller, or of the access point. An OpenRoaming access point must be
manually configured with the Civic and/or the Geo-Spatial coordinates
or able to derive location through other means. For example, an
access point operating in 6 GHz Standard Power mode is required to
include its geo-location in the spectrum grant requests sent to the
AFC. In some environments, the access point can learn the location
information from a connected ethernet switch, or from a broadband
service provider network. Furthermore, any access points supporting
indoor localization services will be able to meet the location
requirement.
It is proposed to re-use the definition of location signaling in
OpenRoaming, enabling the access point to provide the Civic address
and/or the Geo-spatial coordinates of the device or of the access
point to the IDP for CLF population. A confidence-level indicator is
also optionally included in the reported location-data, based on RFC
7459 considerations. This parameter is indicative of the
uncertainity and the confidence level of the reported location.
7. WLAN Network Identification and Selection
The OpenRoaming federation makes extensive use of Passpoint specified
Roaming Consortium Organization Identifiers (RCOIs) for defining
polices that are supported by particular access network providers
(ANPs) and those policies supported by individual identity providers
(IDPs). The supported RCOIs are provisioned in WLAN equipment by the
ANPs and configured in the Passpoint profile of devices managed by
IDPs. Only when there is a match of RCOIs between WLAN and Passpoint
profile will an authentication exchange be triggered. It is proposed
to define the use of an emergency-RCOI for use in the systems to
support Emergency Communication service (e.g. 911/112).
Gundavelli & Grayson Expires 14 July 2024 [Page 12]
Internet-Draft Emergency Communication Services January 2024
8. Legal and Regulatory Requirements
The OpenRoaming federation has a foundation in a legal framework,
whereby the Wireless Broadband Alliance (WBA) as the federation's
policy authority is responsible for defining the framework under
which the federation operates. WBA defines the privacy policy that
providers are required to comply with as well as end-user terms and
conditions. In addition, WBA defines the legal templated terms that
are used between OpenRoaming brokers and OpenRoaming providers,
defining immutable terms that all OpenRoaming providers need to agree
to. Finally, WBA agrees legal terms directly with OpenRoaming
brokers, including terms that require OpenRoaming brokers to use the
WBA templated terms in their agreements with providers. It is
proposed that these legal agreements be amended with terms that cover
operation of emergency service and allow provisions to indemnify ANPs
against any liabilities resulting from emergency call failures.
9. Authentication on the emergency RCOI WLAN
The requirements include being able to support emergency calls for
users without valid credentials to fully authenticate to the WLAN, in
this case a credential that has been issued by a specific OpenRoaming
IDP designated to support users without a full credential. 3GPP has
defined an approach that uses a 3GPP defined vendor specific EAP
method called EAP-3GPP-LimitedService for supporting devices without
credentials. However, this vendor specific EAP method is not widely
supported. Instead, this use-case leverages the well supported EAP-
TTLS method with a common set of credentials used by all users
wanting to access on the emergency-RCOI WLAN. The EAP-Identity shall
be specified as anonymous@sos.fcc-authorized.org with common
credentials being used in the inner method.
10. Authentication using the sos.fcc-authorized.org realm
OpenRoaming dynamically discovers the signaling peers used to
authenticate end-users using DNS. The same approaches are re-used by
ANPs to discover the signaling systems used to support the EAP-server
for the sos.fcc-authorized.org realm. The EAP-server will use the
common credentials to authenticate users without valid OpenRoaming
credentials onto the WLAN. OpenRoaming defines the RADIUS messages
exchanged between ANP and IDP. These include the "offered-service"
vendor specific attribute as well as RFC 5580 defined location
attributes. It is proposed to define a new value for the offered
service, e.g., "openroaming-emergency" to unambiguously indicate that
the authentication has come from a WLAN configured with the emergency
RCOI.
Gundavelli & Grayson Expires 14 July 2024 [Page 13]
Internet-Draft Emergency Communication Services January 2024
11. Emergency CSCF operation for end-users using sos.fcc-authorized.org
credentials
Whereas 3GPP defines the E-CSCF as always operating in the access
network, in this use-case the E-CSCF is a common function that can be
leveraged by all OpenRoaming ANPs that have configured the emergency-
RCOI. This means that the E-CSCF isn't coupled to the access network
by which it can recover network provided location information.
Instead, in this use-case we leverage the existing OpenRoaming
specifications that define the signaling of civic and geo-spatial
location in the RADIUS exchange between ANP and IDP. Unlike in
cellular networks, users on WLAN systems will frequently be allocated
private IP addresses.
This IP address information can be included in the RADIUS exchange
between ANP and IDP, but because it will frequently represent a
private address, it cannot be used to uniquely identify a user.
Instead, it is proposed to enhance the Connectivity Location Function
(CLF) to allow querying based on Basic Service Set ID (BSSID) which
represents the MAC address of the WLAN radio interface that is
serving a user, and optionally a Secure Location Tag (SLT) which the
WLAN system will deliver it to the device.
The BSSID and/or the SLT will be included in the P-ANI SIP header
sent by the device as well as being included in the ANP to IDP RADIUS
signaling. It's proposed that the definition of the IDP hosting the
sos.fcc-authorized.org realm includes support for enhanced CLF
capability that enables the IDP to be queried by an E-CSCF based on
BSSID and/or SLT. The IDP can then match the BSSID and/or SLT with
that received in RADIUS messages originated from individual ANPs and
return the corresponding location information to the E-CSCF.
12. Emergency calling by OpenRoaming subscribers on MNOs
End users who have been provisioned with a full OpenRoaming profile
will successfully authenticate onto the OpenRoaming ANP using their
standard profile and standard OpenRoaming RCOI. As an OpenRoaming
IDP, the MNO is able to similarly match the civic-location and/or
geospatial location of authentication requests with the BSSID and/or
the SLT signaled by the ANP. The MNO operating the CSCF is able to
recover the BSSID and/or the SLT from the P-ANI header and determine
the location of their own users.
13. Call Flows
Gundavelli & Grayson Expires 14 July 2024 [Page 14]
Internet-Draft Emergency Communication Services January 2024
+---+ +---+ +----+ +---+ +---+ +----+ +----+
|Dev| |AP | |DHCP| |DNS| |AAA| |P/E | |PSAP|
+---+ +---+ +----+ +---+ +---+ |CSCF| +----+
| | | | | +----+ |
| | | | | | |
<1> <2> | | <3> | |
| | | | | | |
|<---<4>-->| | | | | |
|<---<5>-->| | | | | |
|<---<6>-->| | | | | |
| |<----------<7>-------->| | | |
| |<----------<8>------------------>| | |
| | <9> | | | |
|<-----------<10>------| | | | |
| | | | | | |
| <11> | | <12> | |
| | | | | | |
|---<13>-->|----------------<14>------------>| | |
|<--------------------------<15>------------>| | |
|<---------|<---------------<16>-------------| | |
|<---<17>->| | | | | |
| | | | <18> | |
|<--------------------------<19>-------------|-------->| |
| | | | |<--<20>--| |
| | | | | <21> |
|<---------------------------------------------------->|<-<22>->|
1. Passpoint Profile with Emergency-RCOI,
ananonymous@sos.fcc-authorized.org.
2. Advertises E-RCOI on that BSSID, Civic & Geo-Location Attributes
configured on the AP.
3. IDP & Voice Services for Emergency Calling. Possibly managed by
FCC or WBA. Manages policies for E-RCOI\nand "sos.fcc.org"
identities.
4. 802.11u with RCOI in Beacon IE
5. Attach to SSID matching the E-RCOI
6. Authentication Exchange (No credential validation)
7. Realm Lookup (sos.fcc.org) / IDP Discovery.
8. TLS Tunnel Setup, Authentication ID federated issued certs.
9. Generates location tag (SLT) based\non device indoor
positioning, or location configuration of the AP.
10. Delivery of SLT from AN over ANQP/AssocResp/DHCP/IPv6 ND
11. BSSID + SLT (optional) + Location Attributes sent to IDP in
the below RADIUS message exchange
12. E-CSCF FQDN and Emergency\nCalling numbers sent to AN in the
below RADIUS message exchange
Gundavelli & Grayson Expires 14 July 2024 [Page 15]
Internet-Draft Emergency Communication Services January 2024
13. EAP-ID/Resp / 802.1x
14. EAP over RADUIUS (TLS)
15. EAP-TTLS with well-known credentials
16. EAP-Success
17. Delivers IMS Configuration over 802.11, DHCP, or IPv6 ND
18. Updates the local CLF to include BSSID and/or SLT to Location
Mapping
19. SIP UA Registration includes BSSID and SLT (optional) in the
P-ANI Header.
20. CLF Query for Location Check using BSSID and/or SLT
21. Determination of PSAP based on query to RDF
22. Emergency Call Routed to PSAP with location
Figure 3: Emergency e911 Services over Wi-Fi Access
Following is some additional text explaining above interactions.
* The device is pre-configured with the emergency passpoint profile,
which includes the emergency RCOI, and a common identity, (e.g.)
"anonymous@sos.fcc.org". This allows the device to discover
access networks that support emergency communication services
(e.g. 911/112).
* The device may be preconfigured with a generic Emergency SIP (non-
IMS) Profile.
* An 802.11 access network supporting EAP-based authentication
method and is part of the OpenRoaming federation is either
configured with the Civic-Location and/or the Geo Spatial
coordinates of the access point or has the ability to derive
location coordinates through other means.
* The access network for supporting emergency services (e.g.
911/112) will advertise the emergency RCOI in the 802.11 Beacon
messages, and furthermore will respond to any ANQP queries on the
supported services.
Gundavelli & Grayson Expires 14 July 2024 [Page 16]
Internet-Draft Emergency Communication Services January 2024
* A device that is in coverage of a WLAN but without any valid
conventional access-network credentials may use the UI interaction
to trigger the selection of the profile containing the emergency
RCOI. The end user's selection of an emergency calling
application, or interaction with the default phone application
(e.g., by selecting the emergency call option in the UI or by
dialing an emergency phone number) may trigger the selection of
the Passport profile with the emergency RCOI, resulting in the
device performing a network-attach for emergency-call access.
* The device will use the default identity, "anonymous@sos.fcc.org"
from passpoint profile in the initial authentication message
exchange, allowing the access network to discover the AAA server /
IDP for EAP authentication.
* The access network using the realm portion of the identity,
"sos.fcc.org." will perform a DNS lookup the AAA server for the
IDP supporting the emergency RCOI and the realm.
* The access network and the AAA server will establish a secure TLS
tunnel for securing the 802.1x/EAP traffic between the device and
the IDP. The authentication of the peers will be based on the
OpenRoaming federation issued X.509 certificates.
* The device will complete the EAP authentication using the common
credentials from the emergency passpoint profile. The 802.1x/EAP
messages are tunneled as RADIUS messages between the access point
and the AAA server.
* The access point will generate secure location tag (SLT) for the
device. The SLT will be delivered to the device over one of the
protocols (ANQP/802.11/DHCP/IPv6 ND). SLT is a tag representative
of the device' location. In another variation, SLT can be a
composite object composed of a signed location by the access
network or a cloud function, along with the identifiers of the
signing entity. Functions such as E-CSCF will be able to verify
the location by verifying the signature of the signing entity.
* Prior to including the access network reported Civic Location, the
Identity Provider (IDP) has the option to conduct a location
validation check. If the reported location fails the validity
test, the IDP can still add the location entry to the CLF.
However, the entry can be flagged to indicate that the address did
not pass the location validation test.
* The access point includes the BSSID of the access point in the
Calling-Station-Id attribute (RFC 2865) and/or the SLT in a new
attribute to be defined.
Gundavelli & Grayson Expires 14 July 2024 [Page 17]
Internet-Draft Emergency Communication Services January 2024
* The access point will also include the attributes for carrying the
Civic Location and/or the Geo-Spatial coordinates of the access
point (RFC 5580).
* The AAA server will send the IMS configuration (E-CSCF FQDN)
supporting emergency call routing services to the access point.
* A success EAP transaction between the device and the AAA server
will result in the AAA server sending EAP-SUCCESS to the device.
* The AAA server will update the local CLF function with the
location of the access point, using BSSID and/or the SLT as
location identifiers.
* The access point delivers the IMS configuration to the client over
one of the interfaces (802.11/ANQP/DHCP/IPv6 ND). ANP will apply
policies which limits the usage of the network over emergency RCOI
only for emergency calling. Furthermore, the ANP will apply QoS
policies on the emergency session for ensuring the call meets the
SLA defined for the emergency service. ANP will prioritize
traffic and sessions on emergency RCOI over other RCOIs.
* The IMS client in the device performs registration with the
emergency IMS system. The UA inserts the P-Access-Network-Info
header field in the SIP message using the 3GPP 24.229 defined
fields. It contains the BSSID of the access point (access-
type="IEEE-802.11", wlan-node-id="BSSID", and optionally a secure-
location-tag=SLT). A new parameter, "secure-location-tag" will be
defined.
* The E-CSCF function uses the BSSID and/or the SLT from the P-ANI
header for determination of the device's location. It queries the
CLF for retrieving the Civic and/or the Geo-spatial coordinates of
the access point. The E-CSCF function may query the RDF function
for the PSAP destination address.
* The E-CSCF will route the emergency call to the nearest PSAP.
14. IANA Considerations
This document does not requires any IANA actions.
Gundavelli & Grayson Expires 14 July 2024 [Page 18]
Internet-Draft Emergency Communication Services January 2024
15. Security Considerations
A rogue user or a compromised device may potentially trigger a volume
of emergency calls, including calls spoofing the caller's real
location. The value set for the field, "i-wlan-node-id" in the PANI
header can potentially be a false BSSID which maps to a different
location in the CLF database.
In this use-case, we eliminate this threat with the use of SLT
(Secure Location Tag) that the network will generate dynamically and
will provide it to the device for inclusion in emergency call
signaling.
A trusted OpenRoaming access network signals the same location tag
along with the civic and/or geo-spatial coordinates to the IDP. The
CSCF function will retrieve the SLT from the call signaling from the
device and will look up the civic location and/or geo-spatial
coordinates of the device by querying the CLF database populated by
the IDP. SLT serves as an index to the real-location and the
generated tag is valid for a short duration, thereby eliminating any
replay attacks.
A rogue user or a compromised device may also initiate a volume of
emergency calls, including a valid caller's location. This threat is
not a new threat and exists even in today's emergency services
supported over wireline and cellular architectures.
16. Acknowledgements
We had many discussions with the members of FCC CSRIC 8 WG and that
feedback greatly us greatly in developing this proposal.
Special thanks to Brian Rosen for a through review and detailed
comments and advice. We also like to thanks Dale R. Worley, Roland
Jesske, and Christer Holmberg for all the discussions.
Finally, we like to thank ART area director, Murray Kucherawy and
DISPATCH working group chairs for facilating the discussions in the
working group.
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Gundavelli & Grayson Expires 14 July 2024 [Page 19]
Internet-Draft Emergency Communication Services January 2024
17.2. Informative References
[I-D.tomas-openroaming]
Tomas, B., Grayson, M., Canpolat, N., Cockrell, B. A., and
S. Gundavelli, "WBA OpenRoaming Wireless Federation", Work
in Progress, Internet-Draft, draft-tomas-openroaming-00,
14 June 2023, <https://datatracker.ietf.org/doc/html/
draft-tomas-openroaming-00>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
<https://www.rfc-editor.org/info/rfc4119>.
[RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4676,
DOI 10.17487/RFC4676, October 2006,
<https://www.rfc-editor.org/info/rfc4676>.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<https://www.rfc-editor.org/info/rfc5222>.
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, DOI 10.17487/RFC5985, September 2010,
<https://www.rfc-editor.org/info/rfc5985>.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
"Dynamic Host Configuration Protocol Options for
Coordinate-Based Location Configuration Information",
RFC 6225, DOI 10.17487/RFC6225, July 2011,
<https://www.rfc-editor.org/info/rfc6225>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011,
<https://www.rfc-editor.org/info/rfc6442>.
Gundavelli & Grayson Expires 14 July 2024 [Page 20]
Internet-Draft Emergency Communication Services January 2024
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
2011, <https://www.rfc-editor.org/info/rfc6443>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<https://www.rfc-editor.org/info/rfc6881>.
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency
Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
<https://www.rfc-editor.org/info/rfc7852>.
[RFC8876] Rosen, B., Schulzrinne, H., Tschofenig, H., and R.
Gellens, "Non-interactive Emergency Calls", RFC 8876,
DOI 10.17487/RFC8876, September 2020,
<https://www.rfc-editor.org/info/rfc8876>.
[TS23501] 23.501, 3. T., "Numbering, addressing and identification",
2021.
Authors' Addresses
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sgundave@cisco.com
Mark Grayson
Cisco
11 New Square Park
Bedfont Lakes
United Kingdom
Email: mgrayson@cisco.com
Gundavelli & Grayson Expires 14 July 2024 [Page 21]