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

[Henning Schulzrinne <[e-mail]>]

Some comments inline.

On Nov 21, 2011, at 9:08 AM, Richard Barnes wrote:

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

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

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.


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

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.


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


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