Re: [Ecrit] [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Brian,

Thanks. I am breaking the discussion into two parts, responding to the comment on traceability.

There are two aspects here: a.) Traceability of the call to a device, b.) Traceability to a user. In many cases, relation between a user a device can be established.

The emergency passpoint profile in question, includes the elements required for the device to make the network selection, use a set of credentials for completing authentication with the identified IDP for the realm.  Based on the chosen approach, these credentials in the passpoint profile can be per-user or common credentials.  If the requirement is user-traceability the device needs to have a user-specific credentials / profile, otherwise common credentials/profile would do it. The specification does not limit this to only one approach, meaning, the either the use of unique or common credentials can be supported.

This in conjunction with the signaling of the device identifier in EAP will allow traceability of the device where the call originated from. For example, there is the EAP Attribute: AT_MN_SERIAL_ID, which can include device identifiers such as IMEI). We can perhaps extend this to include certificate id or other non-cellular device identifiers.

This should meet the requirement that you have captured below. At the same time, looking at the current 3GPP system emergency calling, it appears there is no user-traceability requirement as access emergency without a SIM is permitted. They seem to be supporting different modes, I guess this is for meeting different regular domain requirements. However, IMEI (which is the device identifier is being signalled. That makes me wonder how user-traceability is possible in all cases if there is no SIM auth? Mere inclusion of IMEI will not allow user traceability.


>
Four different behaviours of emergency bearer support have been identified as follows:
a. Valid UEs only. No limited service state UEs are supported in the network. Only UEs that have a valid subscription, are authenticated and authorized for PS service in the attached location are allowed. UEs should be attached to the network and then perform a PDN Connection Request when an IMS emergency session is detected by the UE.
b. Only UEs that are authenticated are allowed. These UEs must have a valid IMSI. These UEs are authenticated and may be in limited service state due to being in a location that they are restricted from service. A UE that can not be authenticated will be rejected.
c. IMSI required, authentication optional. These UEs must have an IMSI. If authentication fails, the UE is granted access and the unauthenticated IMSI retained in the network for recording purposes. The IMEI is used in the network as the UE identifier. IMEI only UEs will be rejected (e.g., UICCless UEs).
d. All UEs are allowed. Along with authenticated UEs, this includes UEs with an IMSI that can not be authenticated and UEs with only an IMEI. If an unauthenticated IMSI is provided by the UE, the unauthenticated IMSI is retained in the network for recording purposes. The IMEI is used in the network to identify the UE.
>

On the SIP callback, if we support user-specific credentials, I guess it should be sufficient.


Regards
Sri



From: Brian Rosen <[e-mail]>
Date: Thursday, April 13, 2023 at 10:12 AM
To: Sri Gundavelli <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <[e-mail]>, "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

The emergency services are firmly against so-called “unitialiized devices”.  They are stuck with the regulatory requirement that has been put on the providers of such devices to support emergency calls, but they would be strongly against expanding the scope of such devices: there are roughly no cases of real emergency calls using such devices, and many, many cases of false emergency calls that cannot be traced to the caller.  I would strongly suggest you don’t pursue such an expansion of that requirement.  It’s a bad idea, and it doesn’t do what proponent’s hoped it would do.  We have substantial real world experience.

You need a reliable identity that can be traced to a real person.  It’s never ironclad (pre-paid cellular for example), but it has to work most of the time.

I’m still confused who the entity that is providing the SIP path is supposed to be.  Are you expecting the WiFi access point owner to do that or some mobile network operator?  If it’s the WiFi AP owner, then they don’t have an interconnect in most cases: they might have a PBX on that network with a PSTN interconnect (like a SIP Trunk) that supports emergency calling, but that’s fairly far removed from the WiFi network and assuming they will allow a random WiFi user to connect to their AP, and then provide a SIP path to emergency services seems very far fetched to me.

But if it was some kind of mobile network operator, what relationship do they have with the enterprise that has the AP?

Callbacks require identity: see above

Brian



On Apr 13, 2023, at 11:25 AM, Sri Gundavelli (sgundave) <[e-mail]> wrote:

Hi Brian,

Thanks for the follow-up. These are very good comments. In the revised version, we will capture all these points.

On the requirement around interconnect to emergency network, we are thinking the FCC designated entity providing identity and voice services for the realm, “sos.fcc-authorized.org<http://sos.fcc-authorized.org/>” will be able to meet the requirements, and the interconnect will be similar to how any MNO’s IMS interconnect is realized today. We will analyze this and add some text.

On traceability comment, the current cellular systems allow emergency call from a device with an expired SIM subscription, or no SIM card. At least in some countries this is allowed. Most GSM phones allow calling of emergency numbers without a SIM card, 112, 911, 118, 000, 110, 08, and 999. Calling these numbers will force the device to use any available network. I need to check the call flow if there is exchange of IMEI, but AFAIK there is no traceability there. In the proposal we have we require the use of emergency passpoint profile, it is possible to signal device specific identifiers in the signaling, and that is one way to realize device traceability. We already have mechanisms for location traceability. But, this allows traceability to a device, not to a person. Mark may have some additional thoughts here.

On the call backs, once the device is able to perform SIP registration with the emergency SIP proxy, it will be possible to support the callbacks. Will analyze this in detail.

Regards
Sri







From: Brian Rosen <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 12, 2023 at 4:36 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Christer Holmberg <[e-mail]<mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail]<mailto:[e-mail]>>, ECRIT <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

<moving to ecrit>
Some entity has to connect to the emergency network (in North America and EU Next Gen systems, this is the “Emergency Services IP Network” or ESInet.  Although the standards say that calls must be accepted over the Internet, in practice all current implementations have direct interconnect between the originating service provider and the ESInet.  If it’s an IMS network operator, they have such connections, and would use their E-CSCF.  I think it’s pretty unlikely that they would support a non-IMS call path.  But there has to be some OSP.  It could be an enterprise, as long as the enterprise permitted access, had a reasonable authentication system tied to some kind of identity and a SIP proxy server.

The emergency authorities don’t like unauthenticated calling sources.  That is how we get swatting.  So your proposal has to describe what identity is, and how that’s traceable to a real person.  You also have to describe how we do call-backs to the caller.

Brian



On Apr 4, 2023, at 1:38 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

HI Roland,

Thank you for your comment.

I agree,  if IMS is unavailable P-CSCF/E-CSCF will all be unavailable.  The key point is non-availability of the cellular network, for PDU creation and/or accessing emergency voice functions. This goes back to Christer’s comment suggesting to use non-IMS terminology.  We will work on that.

On your other comment, access to IMS for wired/wireline devices with IMS-only subscription is a possibility. But we still need to allow the device to connect to the available hotspot with no access-network credentials and be able to obtain the IMS configuration. The IMS network in question can be based of a generic IETF defined voice function, which can do call routing to the PSAP. If a MNO is willing to let their IMS network be available for wired and non-cellular devices, that is an option.

Once the device gets connectivity to the access network based on the special emergency passpoint profile, the access network can deliver the associated IMS/voice-service configuration options to the device. The realm that we are proposing sos.fcc-authorized.org<http://sos.fcc-authorized.org/> and associated IDP can be configured with the IMS/voice-service configuration. These IMS/voice-service functions can be from an MNO, or some other service provider that FCC will authorize.

These configuration options will be signaled from the IDP to the access network, and in turn will be delivered it to the device over DHCP/ND/802.11. The device can perform registration with those voice functions and can initiate the emergency call.

Regards
Sri




From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 4, 2023 at 12:44 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi,
What does this mean that IMS is unavailable?
When IMS is unavailable also the Emergency service (E-CSCF) is unavailable.

Did you also discover the IMS Access possibilities with Digest, where you have an IMS Subscription w/o any RAN connectivity and only via wireline/WIFI?

Best Regards

Roland

Von: dispatch <[e-mail]<mailto:[e-mail]>> Im Auftrag von Sri Gundavelli (sgundave)
Gesendet: Montag, 3. April 2023 16:56
An: Christer Holmberg <christer.holmberg=[e-mail]<mailto:christer.holmberg=[e-mail]>>; Brian Rosen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Mark Grayson (mgrayson) <[e-mail]<mailto:[e-mail]>>
Betreff: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi Christer,

Yes, 3GPP does define the interworking architecture with Wi-Fi, where the UE can use Wi-Fi to reach 3GPP core network for PDU establishment. The scenario that we have and what FCC CSRIC 8 looked into is where H-PLMN/V-PLMN and IMS is unavailable. Also, the interworking procedures assume there is Wi-Fi access connectivity. The access network in question may not have any relation to the operator for the UE to perform SIM based authentication to the access network.

The UE may not even have a cellular modem or SIM/eSIM credentials. What are trying to enable is allow the device to use a special emergency passpoint profile for connecting to any of the available hotspots that support emergency calling services. The device may be Wi-Fi only or a dual-radio capable device. Furthermore, if I see the carrier documentation for Wi-Fi calling, it requires the user to configure a civic address prior making any emergency call, and which a caller in distress may never configure. We are addressing this issue, by allowing a trusted access network with the federation issued certificates to signal the location over RADIUS to the IDP/CLF, which the network can cross correlate with the reported location in the SIP signaling.

<image001.png>

Regards
Sri


From: Christer Holmberg <christer.holmberg=[e-mail]<mailto:christer.holmberg=[e-mail]>>
Date: Monday, April 3, 2023 at 3:21 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, Brian Rosen <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi,

Note that 3GPP has defined emergency calls over WiFi, so please indicate how your draft relates to that work.

Regards,

Christer

From: dispatch <[e-mail]<mailto:[e-mail]>> On Behalf Of Sri Gundavelli (sgundave)
Sent: Saturday, 1 April 2023 4.53
To: Brian Rosen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Mark Grayson (mgrayson) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi Brian,

Sure. Will move the discussion to ECRIT.

Thanks for the pointers to the LoST and PIDF-LO work. Will add some considerations on how devices capable of LoST can obtain location-specific service configuration.


  *   LoST also provides the mechanism to validate location (which you do at configuration time) to make sure the location you send is known by the emergency services.

Ok. We will analyze this. If the mechanisms around Location-validity also covers the cases around detecting rogue/compromised clients, beyond making sure the claimed civic address exists, it will be very useful know. Will add the considerations.


  *   The text has to say how the device uses the location it discovers to make a call (‘perform”), which is what RFC6881 describes.  There are some practical differences in how NG9-1-1 and NG1-1-2 actually work that has to be taken into consideration when looking at 6881.

Ok. Thanks for the pointers. Will add these considerations.


Regards
Sri

From: Brian Rosen <[e-mail]<mailto:[e-mail]>>
Date: Friday, March 31, 2023 at 11:05 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

I do think discussion on this draft should move to ecrit.

Obtaining the regulatory specific calling service configuration (including the numbers) is defined in LoST (RFC5222).
The location must be provided in PIDF-LO form (RFC4119 and its updates).  That is the form (at least the actual location information part) that you use to query the LoST server to get the configuration data and the form of the data you send to the emergency services.
LoST also provides the mechanism to validate location (which you do at configuration time) to make sure the location you send is known by the emergency services.
The text has to say how the device uses the location it discovers to make a call (‘perform”), which is what RFC6881 describes.  There are some practical differences in how NG9-1-1 and NG1-1-2 actually work that has to be taken into consideration when looking at 6881.

Brian


On Mar 31, 2023, at 4:55 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Brian,

Thanks a lot for reviewing the document. I agree, the document should provide the larger emergency calling context. The current art, the elements in the system, interfaces with the PSAPs and other touch points. We are familiar with the prior efforts in IETF and also standards bodies including 3GPP and around ATIS reports. Perhaps a discussion on how NG911/NG211 emergency service network are deployed will be useful. The document requires more work, and this is just a starting point.

The key technical objective for this work is around enabling a Wi-Fi capable device to be able to discover hotspots that support emergency calling, ability to perform a network attach, be able to obtain the regulatory-domain specific calling voice service configuration (including emergency calling numbers) and be able to perform the emergency call. The focus is also on how the network can obtain the location of the emergency caller and the mechanisms for detecting rogue device signaling incorrect location.  Finally, some considerations on the emergency passpoint profiles that are required to be present on the device. This work complements the prior IETF efforts on emergency support for greatly improving the access to emergency services. There are tens of thousands of Wi-Fi hotspots supporting Wi-Fi roaming based on passpoint standards. This approach allows the devices to be able to use any of those hotspots for making that emergency call.

On the choice of the draft title, we do understand the emergency calling numbers are specific to the regulatory domain in question and the proposed approach is not specific to any one regulatory domain. In that sense, we should have been bit more sensitive about this. We will modify the draft title to be generic and not specific to one regulatory domain.

Thanks a lot for the feedback.

Regards
Sri



On 3/31/23, 2:02 AM, "Brian Rosen" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>> wrote:


I have read this draft.


It is totally lacking context of current and evolving standards in emergency calling, including:
1. Basic IETF emergency calling standards (/RFC4119/RFC5222/RFC5985/RFC6881)
2. NG911 and NG112 standards that are being deployed, which are based on the IETF standards
3. ETSI and ATIS standards that support the above


While I don’t know enough about WiFi or some of the 3GPP standards to comment on the technical approach in the doc, I am intimately familiar with what is deployed, and about to be deployed in emergency calling and this doc can’t begin to get considered until it deals with the issues associated with the IETF/NENA/EENA/ETSI/ATIS work.


As a really simple start, authors might consider that 9-1-1 is North America only, while the IETF is world-wide.


Brian





On Mar 27, 2023, at 12:35 AM, Sri Gundavelli (sgundave) <sgundave=[e-mail]<mailto:sgundave=[e-mail]> <mailto:[e-mail]>> wrote:

Dear All:

Attached is the link to the document on Supporting emergency 911 services over Wi-Fi. The attached document proposes an approach based on WBA's Wi-Fi OpenRoaming and uses many other elements which are already in standards.

We are looking for some technical feedback. We believe there is value in IETF identifying new methods for improving e911 service access.

Appreciate any feedback.

Regards
Sri



Name: draft-gundavelli-dispatch-e911-wifi
Revision: 00
Title: Emergency 911 Services over Wi-Fi
Document date: 2023-03-13
Group: Individual Submission
Pages: 15
URL: https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt&gt;>
Status: https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/ <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/&gt;>
Htmlized: https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi&gt;>




Abstract:
Proposed is an approach for supporting emergency 911 services over
IEEE 802.11 based Wi-Fi access networks. This approach leverages the
legal framework and the building blocks of the OpenRoaming federation
for extending emergency 911 calling support to already deployed tens
of thousands of OpenRoaming Wi-Fi hotspots. The proposal addresses
the key issues in emergency calling, around discovery and
authentication to access network supporting emergency services,
emergency access credentials, location determination of the emergency
caller, and delivering emergency voice service configuration to the
device and call routing.








The IETF Secretariat







_______________________________________________
dispatch mailing list
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>