Subject: [Ecrit] draft-ietf-ecrit-unauthenticated-access-03

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Nov 2011 23:01:18 +0800

Hi all, 

in today's ECRIT meeting there was not enough time to discuss the details of the open issues. We also spent a lot of time on justifying the draft even though we had made that decision already a long time ago. 

In any case, here are the open issues: 

1) No Access Authentication (NAA)

I suggested to address the fraud problem that results from a host that attaches to a network using some special link layer authentication procedure without actually having credentials for that specific network by not routing the emergency calls via the VSP but instead contacting the PSAP directly. 

From the feedback during the meeting I believe folks are fine with that approach but are looking forward to see the details. 

2) Deployment Reality

Bernard and Martin had some comments about the current deployment limitations of many access networks. For example, many hotspots require user interactions prior to get network access granted. There is not really anything we can do about it other than mentioning the challenges in a limitation section. I suggested to introduce such a section. 

3) Lack of authorization to perform network access

The document currently considers the Zero-Balance ASP where an emergency caller is not authorized to make the emergency call. This lack of authorization is visible at the application layer. Bernard suggested to add a discussion about lack of authorization at the network layer as well. 
I am OK with adding such text. 

4) Writing Style

Martin suggested to restructure the document, i.e. to change the writing style. I would like to leave the structure at the moment as is.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Nov 2011 10:17:38 -0500

2) HotSpot 2.0 should help with that problem in the longer run. (Indeed, our requirements might shape the evolution of that effort, particularly if we can reach out to that group.)

On Nov 16, 2011, at 10:01 AM, Hannes Tschofenig wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Nov 2011 09:08:44 -0500

> From the feedback during the meeting I believe folks are fine with that approach but are looking forward to see the details. 

This approach actually makes me nervous.  As others have pointed out in several contexts, code paths that only get exercised in emergencies tend to be less reliable than the normal code paths.  So we might RECOMMEND that the calling device go directly to the PSAP, we should allow that it MAY use a VSP.

The fraud risks are probably not that daunting.  As with the trustworthy-location / PSAP protection cases, there are several "softer" mitigations that can be applied here.  For example, you could limit the type and number of flows per endpoint to something that looks like VoIP, e.g., allowing a single SIP or TLS session and some number of RTP/SRTP flows.  This may start to sound like DPI, but really you can do it mostly at the TCP/IP layer.

> Bernard and Martin had some comments about the current deployment limitations of many access networks. For example, many hotspots require user interactions prior to get network access granted. Ther…

The general question is how endpoints determine which state they're in -- namely, do they have a real Internet connection or not.  There are actually some deployed solutions to this today.  If you look at Mac OS X Lion or recent versions of iOS, they do a test HTTP query to an Apple server and see if they get the right response back.  I understand that Blackberry devices do something similar.  

It might be worthwhile to write an RFC standardizing a mechanism for this, to make the whole system more predictable in general (not just in emergency cases).  I've been meaning to bring this up in APPSAWG, but haven't gotten around to it.   

> I am OK with adding such text. 

The more I think about it, the more absurd this case seems.  ASPs should allow emergency calls.  Rather than requiring special handling on the client side, we should provide guidance to ASPs on how to determine whether a call is an emergency call, using LoST.  

(Someone should build a service that builds a global list of PSAP/ESRP URIs from LoST and distributes it to interested parties.  You could even do something clever like make it a Bloom filter.)

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Nov 2011 09:33:48 -0500

Some comments inline.

> This approach actually makes me nervous.  As others have pointed out in several contexts, code paths that only get exercised in emergencies tend to be less reliable than the normal code paths.  So…

Agreed. This may also be difficult to do due to the architecture of ESInets (hierarchical LoST routing, policy filters at the edge of the ESInet, etc.)

> The fraud risks are probably not that daunting.  As with the trustworthy-location / PSAP protection cases, there are several "softer" mitigations that can be applied here.  For example, you could l…

I suspect the fraud concern would be "free phone calls". It seems hard to distinguish an emergency voice call from a regular phone call.

One could restrict such calls by bandwidth or duration, but that comes with its own set of issues. (Realistically, few people are going to shell out $10 to make a five-minute phone call via WiFi, so the lost revenue seems small. Counterargument would be the per-minute access offered by Skype.)

For large operators, you could imagine a more sophisticated solution that allows the operator to check whether an unauthenticated access call is indeed an emergency call by querying a database (e.g., by IP address). Such calls are presumably going to be pretty rare. It is not clear whether such a mechanism is worth the deployment, operational and false-negative cost.

> It might be worthwhile to write an RFC standardizing a mechanism for this, to make the whole system more predictable in general (not just in emergency cases).  I've been meaning to bring this up in…

As I mentioned earlier, the HotSpot 2.0 initiative tackles this problem, as far as I can tell. It also tries to avoid splash screens, to deal with mobile devices and seamless handoff.

> (Someone should build a service that builds a global list of PSAP/ESRP URIs from LoST and distributes it to interested parties.  You could even do something clever like make it a Bloom filter.)

It might help if we divide the problem into three cases:

(1) Large, national operators, such as Boingo. They can offer a LoST server and outbound SIP proxy that's keyed to the LoST server URLs. They already maintain white lists of URLs for unpaid access, so this does not seem that hard.

(2) Local paid WiFi, such as in hotels. Somewhat problematic. May need some kind of access duration/speed restriction.

(3) Free WiFi with disclaimer screens (Starbucks, Panera, etc.). Fraud is not a major concern.

Henning

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 21 Nov 2011 09:42:15 -0500

> I suspect the fraud concern would be "free phone calls". It seems hard to distinguish an emergency voice call from a regular phone call.

True.  But at least this limits things to phone calls, as opposed to, say, Netflix or YouTube.  At least until someone sets up a Netflix-to-SIP gateway.

> As I mentioned earlier, the HotSpot 2.0 initiative tackles this problem, as far as I can tell. It also tries to avoid splash screens, to deal with mobile devices and seamless handoff.

HotSpot 2.0 solves the problem for WiFi.  I have run into similar systems on other types of network, including both Ethernet and WiMAX.  So it might be useful to solve this at the Internet level, even if only by reference to the HS2.0 solution.

--Richard