It seems to me that fly in the ointment is this point: > - because the protocol used is opaque, the access provider has no way to > distinguish between session establishment, an actual EC, ordinary IM traffic > or common web browsing (one could envision a VoIP application that uses HTTP > bindings for signaling purposes)
I agree with this point. Effectively it says that the access has no way of knowing whether the third party application actually is just supporting an emergency call. Not only is it opaque but it has no control signalling relationship with the access either - so the access has no independent way to inform the application that the client is only supposed to be doing an emergency call. I do not see how the "it's understood to be an emergency IP context" knowledge facilitates any of this policy control. Out of control is out of control. On you first point about the UI implementation. I have... hang on... five applications on my Android device menu that do voice in one form or another. Frankly, it would be most convenient to have one there that just said "Emergency" and whose sole purpose was to do the ECRIT procedures (as described in this draft). That would be an ECRIT direct calling client. Access networks can most readily support policies that allow for this mode of use - without the third party trust issues that you raise. Cheers, Martin -----Original Message----- From: Andres Kütt [mailto:[email protected]] Sent: Friday, 26 March 2010 10:12 PM To: Dawson, Martin Cc: [email protected]; [email protected] Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Hi, Certainly. Let's assume the following: - existing UI implementation is used (i.e. the software provider will not build a separate SIP client with distinct UI just for emergency calling) - the client is multifunctional i.e. it is used for more things than calling - the client has been authenticated already, this kind of software tends to run in the background continuously - there is no network connection Given these assumptions EC would work like this: - user attempts to place an EC - the client, being offline, attempts to re-establish it's session with the network/server (i.e. get online) - at this point, the access provider needs to know that the session being established is for the purposes of an EC and needs to allow the connection - session gets established with the server/network - user attempts an emergency call - the call reaches servers/network and is connected - the call ends - at this point there needs to be a way to drop the connection as the access provider has no way of knowing whether the call has ended or not. Please note that - session establishment happens before the call and access provider has no idea whether this is because of ordinary client use or EC. Remember, the protocol used is opaque - it is impossible for the client to know whether EC is even allowed/implemented for a particular location before the session is established - because the protocol used is opaque, the access provider has no way to distinguish between session establishment, an actual EC, ordinary IM traffic or common web browsing (one could envision a VoIP application that uses HTTP bindings for signaling purposes) Thus, regardless of the methods used, the access provider needs to trust the service provider to only use the connection for emergency calling and nothing else. As for the session establishment, one way to do this is the way Skype Access (you buy WIFI time using your Skype credit) works: - the client wraps a session request in a DNS query against skype.com name server. DNS is usually quite unrestricted but there are, of course, exceptions - single-use credentials are issued - WISPr authentication is attempted using the credentials acquired - the access provider attempts authentication against Skype - session is established - when the authentication session ends, the access provider attempts a re-authenticate and terminates the connection should it fail Yours, Andres On 3/24/10 12:55 PM, "Dawson, Martin" <[email protected]> wrote: > Hi Andres, > > Could you take us step by step through the establishment of the anonymous > connection and the initiation of the emergency call and highlight where/how > this notification mechanism would be invoked and what it would do? > > I would find that helpful. I'm interested in how people see the access network > being able to limit the use of an arbitrary third party VoIP application to > emergency calling, if that's the intent, in the context of > unauthenticated/anonymous access. > > BTW, I haven't said that access is completely out of scope. Actually, it > obviously is in scope both in terms of what facilities it provides and what > its policies are with respect to emergency calling procedures in the context > of unaurthenticated/anonymous connections. It's the concept of gating the > establishment of unauthenticated/anonymous connections on some kind of a > priori knowledge or indication that its for the purpose of an emergency call > that I question. > > Regards, > Martin > > -----Original Message----- > From: Kutt, Andres [mailto:[email protected]] > Sent: Wednesday, 24 March 2010 9:31 PM > To: Dawson, Martin > Cc: [email protected]; [email protected] > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > Hi, > > Leaving access completely out of scope is of course the easiest course > but some synchronization must remain. In case of Skype, there is no way for > the access provider to tell whether the user is placing an emergency call or > chatting with their friends as the protocol used is opaque for the outsider. > This is true in any case the service provider uses a protocol not known or > understood by access provider and we must assume this can legally occur. > Thus, should anonymous access be required, a mechanism must exist to notify > the access provider about an attempted emergency call. > > Yours, > Andres > > > On 3/24/10 3:14 AM, "Dawson, Martin" <[email protected]> wrote: > >> Consider the access out of scope, certainly. Recommend to access-specific >> forums that they shouldn't *assume* the connecting device is actually the >> device making the emergency call (e.g. a WiFi device on a portable 3G router) >> so there's no reliable assumption the connecting device can provide an >> emergency flag. >> >> Then it's whatever ECRIT might recommend as appropriate on top of IP. I think >> Richard's questions are along the line of what the value of this specific >> "emergency flag" is at the IP level. It's not like anyone but the device user >> knows whether the access really is only required for emergency purposes. It's >> a valid question; access policy may just be to bar or allow (depending on >> whether it's a prohibitive or a permissive policy) access to emergency >> specific things - such as routes to PSAPs. A flag is not necessarily required >> to apply that sort of policy. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email protected]] >> Sent: Wednesday, 24 March 2010 10:14 AM >> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard >> Aboba >> Cc: [email protected]; [email protected] >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>> the DSL forum, etc. as to how a device is able to get an >>> unauthenticated IP context on their technology, for whatever >>> purpose, before the policies on permitting/prohibiting ECRIT >> >> but what is the concrete recommendation that you want to give here? >> >> - Drop the access/ISP part from the draft and say access/ISP is >> out-of-scope? >> - move this to EMU? >> - or deal with the EAP/NAI related aspects outside IETF as you seem to >> suggest (which is already partially the case today due to lack of >> guidance)? >> >>> is on others. I doubt that there's a reasonable assumption >>> that the connecting device can necessarily provide an >>> explicit "emergency intent" flag. >> maybe this is why some people do this via the NAI ;-) >> >> Dirk >> >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] >>> On Behalf Of ext Dawson, Martin >>> Sent: Tuesday, March 23, 2010 11:44 PM >>> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba >>> Cc: [email protected]; [email protected] >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>> >>> To elaborate on Brian's "counter point" - some jurisdictions >>> may prefer to *forbid* access to the emergency service from >>> unauthenticated/anonymous access as opposed to *require* it >>> to be supported. Noting this is the equivalent of saying >>> emergency calls for circuit service cannot be made from >>> public phone booths; this is still a possible policy within a >>> given jurisdiction. >>> >>> I'd also posit that not only is it not a priority for IETF >>> but that the question actually needs to be dealt with in more >>> specific forums first. The ECRIT emergency procedures occur >>> at or above the IP layer. Before anything that ECRIT >>> describes becomes relevant, there needs to be an IP context. >>> >>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>> the DSL forum, etc. as to how a device is able to get an >>> unauthenticated IP context on their technology, for whatever >>> purpose, before the policies on permitting/prohibiting ECRIT >>> procedures or anything else that can be done on IP can be >>> applied. This is easier on some access technologies than it >>> is on others. I doubt that there's a reasonable assumption >>> that the connecting device can necessarily provide an >>> explicit "emergency intent" flag. >>> >>> Cheers, >>> Martin >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] >>> On Behalf Of Brian Rosen >>> Sent: Wednesday, 24 March 2010 8:29 AM >>> To: Thomson, Martin; Richard Barnes; Bernard Aboba >>> Cc: [email protected]; [email protected] >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>> >>> I think the relevant part of this is 'it's not a high >>> priority'. That is >>> policy of the work group, which we do have control over. >>> >>> If we have nothing else more important to do, then by all >>> means, let's waste >>> a ton of time on unauthenticated access. If we have other work to do, >>> perhaps we could defer this. >>> >>> I am not the chair, but in general, anyone can discuss >>> anything, regardless >>> of "priority" on the list. However, when it comes to >>> adopting work group >>> items, I think this should be way down our list. >>> >>> I might also suggest that unauthenticated access really isn't >>> within the >>> charter of the work group. It may be that the reason >>> unauthenticated access >>> may be needed is for emergency calling, but that means we may >>> (eventually) >>> need to ask some other work group to do work for a >>> requirement we generate. >>> It would seem that dealing with EAP is not within the domain >>> of this work >>> group. >>> >>> Brian >>> >>> >>> On 3/23/10 5:14 PM, "Thomson, Martin" >>> <[email protected]> wrote: >>> >>>>> A large percentage (in fact an overwhelming percentage) of >>> PSAPs DON'T >>>>> WANT >>>>> unauthenticated access. Their position is that they have lots of >>>>> relevant >>>>> experience, and its all bad (tens of thousands of calls >>> with no good >>>>> ones in >>>>> some cases). >>>>> >>>>> However, there are some PSAPs who want it, and there are some >>>>> regulatory >>>>> environments where there are some lawyers who think it's >>> required to >>>>> support >>>>> it in some environments. >>>> >>>> The good thing is: we don't set policy here. I'm not >>> seeing sufficient >>>> evidence that _everyone_ doesn't want this, only that some >>> don't want this. >>>> >>>> I can't comment on priority. That would be policy too. >>>> >>>> --Martin >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
