Subject: Re: [Emu] [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Mar 2010 22:59:51 +0100

as spelled out by others already, we need to separate the aspects here.
So the 'unauthenticated' draft intends to cover

1) the VSP/ASP related part
2) the access/ISP part. 
3) unauthenticated access (no credentials)
4) unauthorized cases like empty prepaid account, roaming not allowed
etc, where credentials are available but do not allow regular access.

Considerations for 3) and 4) are different between the VSP/ASP and
access/ISP cases. For the VSP/ASP part, we probably do not need to care
a lot about 4), but for access/ISP this is different. And unfortunately
regulatory requirements for 4) are pretty different from the
unauthenticated case.

Now, regarding EAP: 
Up to now, IETF does not provide any recommendation for 3) and 4). This
made different organizations come up with different incompatible ways to
solve the problem.
The idea behind adding the EAP considerations to our draft was to
discuss whether IETF is able to recommend a common way. Any such
recommendation needs to cover both 3) and 4) (not just unauthenticated).

Dirk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Brian Rosen
> Sent: Tuesday, March 23, 2010 10:29 PM
> To: Thomson, Martin; Richard Barnes; Bernard Aboba
> Cc: [email-masked]; [email-masked]
> 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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Mar 2010 00:14:08 +0100

> 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

> On Behalf Of ext Dawson, Martin
> Sent: Tuesday, March 23, 2010 11:44 PM
> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
> 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
> 
> On Behalf Of Brian Rosen
> Sent: Wednesday, 24 March 2010 8:29 AM

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Mar 2010 04:11:55 +0100

see inline.

Dirk 

> From: ext Dawson, Martin [mailto:[email-masked]] 
> Sent: Wednesday, March 24, 2010 2:15 AM
> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; 
> Thomson, Martin; Richard Barnes; Bernard Aboba
> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial 
> 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.

I do not see a value in such recommendation from IETF would be. 
For layer-2 flags these organizations define such flags. They know.
 
> 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. 
What flag are you refering to? Up to now we were only discussing options
to indicate emergency in EAP, which rather on top of layer-2 than IP.

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.
Without a full subscription (either insufficient authorization or no
subscription) you may want to enter the NW for other things than
emergency. So would you always hotline these entrants to the PSAP?

> From: Kroeselberg, Dirk (NSN - DE/Munich) 
> [mailto:[email-masked]] 
> Sent: Wednesday, 24 March 2010 10:14 AM
> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard 
> Barnes; Bernard Aboba
> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Mar 2010 17:29:17 -0400

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-masked]> wrote:

>> A large percentage (in fact an overwhelming percentage) of PSAPs DON'T
>> WANT
>> experience, and its all bad (tens of thousands of calls with no good
>> ones in
>> some cases).
>> 
>> 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.
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 06:43:55 +0800

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-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, 24 March 2010 8:29 AM
To: Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 09:14:35 +0800

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-masked]] 
Sent: Wednesday, 24 March 2010 10:14 AM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Dirk

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 12:42:23 +0800

Hi Dirk,

> For layer-2 flags these organizations define such flags. They know.

SDOs set their own agendas; that's fair enough. They don't always want to consider how their architectures interwork with specifications defined by, say, the IETF. So perhaps, as you say, it's pointless. While ECRIT procedures are at the IP level and are intended to support clients that are connecting on IP via a routing device at the access, a "link technology SDO" may still persist with the assumption that it's the connecting device that negotiates procedures in an emergency scenario. Alternatively, they may consider the ECRIT model and decide to do something different. It is, as you say, up to them.

> to indicate emergency in EAP, which rather on top of layer-2 than IP.

Which, if I understand it, is about negotiating an IP context in what is also an "emergency context". Leaving aside my point above as to whether that's a generally effective facility for supporting emergency connectivity, there's also the question (which I may be unfairly be attributing to Richard) as to what value it is to the access to know that this connectivity has been granted in an "emergency context". What's it going to do with this alleged context?

> emergency. So would you always hotline these entrants to the PSAP?

No - you wouldn't. But, then, the concept of "hotlining the entrant to a PSAP" refers to a procedure that isn't described by ECRIT. There's no "hotlining". The device knows it wants to initiate an emergency call; it gets location from the LIS, gets the PSAP URI from LoST, and initiates a SIP session to the PSAP. The proposition of "hotlining" based on a layer 2 technology specific procedure is the sort of thing I refer to above. An access technology specific SDO may, for their own reasons, decide to define this sort of thing. I think they're talking about use cases that are orthogonal to what ECRIT is describing. ECRIT describes emergency procedures for the Internet, on IP, and independent of access technology.

I guess the extent to which an SDO thinks these things are worth developing depends on the extent to which they think a) ECRIT is not a significant model or to which b) they think there are "emergency" use cases that are outside the Internet domain or to which c) there is some complementary subset of use cases for their link technology (e.g. WiFi phones in an enterprise environment with an "emergency" button that set up an emergency IP context and are hotlined to the enterprise softswitch that then does ECRIT procedures to the outside world). The SDO just needs to decide whether there is a benefit consistent with the effort in defining/implementing such functionality. I think it's good if their delegates are aware of ECRIT in making that decision.

Cheers,
Martin

-----Original Message-----
From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, 24 March 2010 2:12 PM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

see inline.

Dirk

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 18:55:26 +0800

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-masked]] 
Sent: Wednesday, 24 March 2010 9:31 PM
To: Dawson, Martin
Cc: [email-masked]; [email-masked]
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-masked]> 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
> 
> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of
> serviceattacks on the emergency.com domain)
>

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Mar 2010 16:46:10 +0100

> facility for supporting emergency connectivity, there's also 
> the question (which I may be unfairly be attributing to 
> Richard) as to what value it is to the access to know that 
> this connectivity has been granted in an "emergency context". 
> What's it going to do with this alleged context?

Considering this in authorization decisions, QoS, setting IP filters
(limited access), priority. Just to give a few examples. 

> No - you wouldn't. But, then, the concept of "hotlining the 
> entrant to a PSAP" refers to a procedure that isn't described 
> by ECRIT. There's no "hotlining". The device knows it wants 

Right, but I was saying it is important for the access network to
recognize that the 'special' entry the MS wants to do is for emergency,
not let the access network roll dices.
Of course hotlining procedures are not in scope of ECRIT, there is
nothing emergency-specific besides installing the right filters (which
by the way we also discuss in the draft - should we also drop this?).

Dirk

> Sent: Wednesday, March 24, 2010 5:42 AM
> SDOs set their own agendas; that's fair enough. They don't 
> always want to consider how their architectures interwork 
> with specifications defined by, say, the IETF. So perhaps, as 
> you say, it's pointless. While ECRIT procedures are at the IP 
> level and are intended to support clients that are connecting 
> on IP via a routing device at the access, a "link technology 
> SDO" may still persist with the assumption that it's the 
> connecting device that negotiates procedures in an emergency 
> scenario. Alternatively, they may consider the ECRIT model 
> and decide to do something different. It is, as you say, up to them.
> 
> Which, if I understand it, is about negotiating an IP context 
> in what is also an "emergency context". Leaving aside my 
> point above as to whether that's a generally effective 
> facility for supporting emergency connectivity, there's also 
> the question (which I may be unfairly be attributing to 
> Richard) as to what value it is to the access to know that 
> this connectivity has been granted in an "emergency context". 
> What's it going to do with this alleged context?
> 
> No - you wouldn't. But, then, the concept of "hotlining the 
> entrant to a PSAP" refers to a procedure that isn't described 
> by ECRIT. There's no "hotlining". The device knows it wants 
> to initiate an emergency call; it gets location from the LIS, 
> gets the PSAP URI from LoST, and initiates a SIP session to 
> the PSAP. The proposition of "hotlining" based on a layer 2 
> technology specific procedure is the sort of thing I refer to 
> above. An access technology specific SDO may, for their own 
> reasons, decide to define this sort of thing. I think they're 
> talking about use cases that are orthogonal to what ECRIT is 
> describing. ECRIT describes emergency procedures for the 
> Internet, on IP, and independent of access technology.
> 
> I guess the extent to which an SDO thinks these things are 
> worth developing depends on the extent to which they think a) 
> ECRIT is not a significant model or to which b) they think 
> there are "emergency" use cases that are outside the Internet 
> domain or to which c) there is some complementary subset of 
> use cases for their link technology (e.g. WiFi phones in an 
> enterprise environment with an "emergency" button that set up 
> an emergency IP context and are hotlined to the enterprise 
> softswitch that then does ECRIT procedures to the outside 
> world). The SDO just needs to decide whether there is a 
> benefit consistent with the effort in defining/implementing 
> such functionality. I think it's good if their delegates are 
> aware of ECRIT in making that decision.
> 
> Cheers,
> Martin
>

---

From: "Kutt, Andres" <[email-masked]>
Date: Wed, 24 Mar 2010 10:31:18 +0000

Hi,

Yours,
Andres

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 25 Mar 2010 05:01:37 +0100

there is no EAP in your scenario as this is open WiFi, so of course any
EAP-based emergency indicator would not apply to it. However, there are
other scenarios.

So what you are basically saying with your example is that network
access authentication is only based on EAP for certain scenarios. Sure,
this is correct (not sure whether this is clear in the draft, I will
check). For open WiFi access we can only provide high-level guidance
like the one you describe below. 
For EAP this can be more specific, if something is agreeable. If not,
fine. However, looking at this whole thread, it makes much sense to me
to adjust and keep the section instead of not capturing the whole
discussion. 
What is probably missing at the moment are figures that clarify the
relation between access/ISP and VSP/ASP for unauthenticated and
unauthorized cases. We are planning to add such figures.

Dirk 

> Sent: Thursday, March 25, 2010 3:16 AM
> To: Kroeselberg, Dirk (NSN - DE/Munich)
> I'll describe a potential real world scenario before I try to 
> answer your question.
> 
> * Public WiFi hotspots generally provide a "free 
> unauthenticated and anonymous" IP context.
> 
> * Once connected to the access, users are generally "portal 
> locked" to a single web page that requires further 
> authentication/payment to proceed. The access may provide 
> some additional "filters" that allow routes to some subset of 
> news/commercial websites as a "bonus".
> 
> * In order to support unauthenticated/anonymous emergency 
> calling at this point, the hotspot would need to add the 
> location service, access to LoST, and a route to the relevant 
> PSAP URI(s) to the filter list.
> 
> The question I raise is what would be done differently if the 
> connecting device *could* have provided an indication that it 
> wanted the connection for the purpose an emergency call? I 
> don't think anything needs to be done differently. I don't, 
> for example, think there's any prioritization benefit. An 
> "emergency" type query to the LCP (HELD option), an emergency 
> service lookup to LoST, and a SIP session directed toward a 
> PSAP URI are all things that could be explicitly detected and 
> given priority. Priority isn't an end-goal in itself in any 
> case. The end goal is reliability and response time for these 
> emergency related services. The access provider may need to 
> ensure some service level there. They can do that without 
> needing to roll dice. And, given they can neither rely on 
> devices to provide an emergency indication nor trust that 
> indication if they do, they are likely better off providing 
> the necessary service level for emergency procedures 
> independently of the device's broadcasted intentions.
> 
> Let me say that I think the draft is great; it crystallizes a 
> lot of issues. I just think the section on EAP isn't 
> necessary; it doesn't describe a generally applicable 
> solution and its presence is likely to cause confusion as to 
> its significance. In answer to your question; no, I don't 
> suggest dropping the discussion on filters. I think that's a 
> fundamental aspect; I think it's orthogonal to the concept of 
> an "emergency intent indicator".
> 
> Cheers,
> Martin
> 
> 
> 
> Sent: Thursday, 25 March 2010 2:46 AM

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 25 Mar 2010 10:15:59 +0800

I'll describe a potential real world scenario before I try to answer your question.

* Public WiFi hotspots generally provide a "free unauthenticated and anonymous" IP context.

* Once connected to the access, users are generally "portal locked" to a single web page that requires further authentication/payment to proceed. The access may provide some additional "filters" that allow routes to some subset of news/commercial websites as a "bonus".

* In order to support unauthenticated/anonymous emergency calling at this point, the hotspot would need to add the location service, access to LoST, and a route to the relevant PSAP URI(s) to the filter list.

The question I raise is what would be done differently if the connecting device *could* have provided an indication that it wanted the connection for the purpose an emergency call? I don't think anything needs to be done differently. I don't, for example, think there's any prioritization benefit. An "emergency" type query to the LCP (HELD option), an emergency service lookup to LoST, and a SIP session directed toward a PSAP URI are all things that could be explicitly detected and given priority. Priority isn't an end-goal in itself in any case. The end goal is reliability and response time for these emergency related services. The access provider may need to ensure some service level there. They can do that without needing to roll dice. And, given they can neither rely on devices to provide an emergency indication nor trust that indication if they do, they are likely better off providing the necessary service level for emergency procedures independently of the device's broadc
 asted intentions.

Let me say that I think the draft is great; it crystallizes a lot of issues. I just think the section on EAP isn't necessary; it doesn't describe a generally applicable solution and its presence is likely to cause confusion as to its significance. In answer to your question; no, I don't suggest dropping the discussion on filters. I think that's a fundamental aspect; I think it's orthogonal to the concept of an "emergency intent indicator".

Cheers,
Martin

-----Original Message-----
From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, 25 March 2010 2:46 AM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Dirk

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2010 22:40:34 -0400

With non-web devices, it's becoming more common to have 802.1x as a second authentication option, beyond the splash page. (indeed, just yesterday I got word that my employer is transitioning to this, and this is how many, if not most, European universities work). The motivation is that entering authentication data on some WiFi devices, such as digital cameras or even smart phones, is painful. Thus, having a mode to bypass normal 802.1x processes for emergency purposes can be quite useful.

I don't think that this will be all that common immediately or even in the next year or two, but there's no reason not to encourage such new architectures if we believe they are useful for public safety. After all, I thought our goal is to enable (legitimate) emergency calls, not to prevent them.

As proposed, the system would allow unrestricted access for emergency purposes. I realize some have some difficulty fathoming why a provider would do this, but the cost to the ISP (or campus, or hotel) is minimal, so consider it the equivalent of providing pull boxes for fire alarms. I consider it the equivalent of a "emergency exit only" sign - they are abused rarely and there are processes in place to deal with abusers. You don't fix the problem by putting a stronger lock in front of the emergency exit. I guess you can consider it the "picket fence" theory of security. The "sos" user ID is essentially a picket fence that will allow socially useful behavior. 

Henning

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 26 Mar 2010 12:11:21 -0000

> With non-web devices, it's becoming more common to have 
> 802.1x as a second authentication option, beyond the splash 
> page. (indeed, just yesterday I got word that my employer is 
> transitioning to this, and this is how many, if not most, 
> European universities work).

Speaking for my own customers (UK education), and what I know about
other European universities, EAP is invariably the primary mode of
authentication. Web-based authentication, if offered, typically provides
access to a more tightly controlled network (and often one which uses
different backhaul from the primary Campus connection).

In any event, I would encourage you to consider a solution that avoids
the use of EAP. EAP makes most sense where you have non-trivial policies
to enforce. I don't think that's the case here. If you all need is some
very limited connectivity, something like (for example) a well-known
SSID that only forwarded to a well-known address would probably be
acceptable to our customers.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Andres Kütt <[email-masked]>
Date: Fri, 26 Mar 2010 13:11:57 +0200

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-masked]> 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
> 
> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 27 Mar 2010 08:51:05 +0800

> 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-masked]] 
Sent: Friday, 26 March 2010 10:12 PM
To: Dawson, Martin
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Hi,

Please note that

Yours,
Andres

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 02:17:16 +0200

In an RSNA enabled wifi network you are not redirected to a portal page, but rather authenticated (if you have the key) before getting associated. If you do not know the key, you can't associate, and can't send any 802.11 data packets to the AP. If there was an indication included in the EAP Request, then the AP would know that this STA is requesting association for emergency call purposes, and may be able to give access to it even if the STA is not in posession of the proper credentials (installing filters would still be necessary).

For open access wifi networks, the 802.11 specification has a slightly different solution than the one suggested below: the AP may be configured with multiple SSIDs, with one of them being dedicated for emergency call purposes. This is then signalled in the beacon frame. STAs willing to place an emergency call would first perform an active scan, identify the proper SSID and associate (RSNA is not supposed to be enabled).

-- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Dawson, Martin
Sent: Wednesday, March 24, 2010 7:16 PM
To: Kroeselberg, Dirk (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

The question I raise is what would be done differently if the connecting device *could* have provided an indication that it wanted the connection for the purpose an emergency call? I don't think anything needs to be done differently. I don't, for example, think there's any prioritization benefit. An "emergency" type query to the LCP (HELD option), an emergency service lookup to LoST, and a SIP session directed toward a PSAP URI are all things that could be explicitly detected and given priority. Priority isn't an end-goal in itself in any case. The end goal is reliability and response time for these emergency related services. The access provider may need to ensure some service level there. They can do that without needing to roll dice. And, given they can neither rely on devices to provide an emergency indication nor trust that indication if they do, they are likely better off providing the necessary service level for emergency procedures independently of the device's broadc  asted intentions.

Cheers,
Martin

-----Original Message-----
From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, 25 March 2010 2:46 AM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

> facility for supporting emergency connectivity, there's also the
> question (which I may be unfairly be attributing to
> Richard) as to what value it is to the access to know that this
> connectivity has been granted in an "emergency context".

Considering this in authorization decisions, QoS, setting IP filters (limited access), priority. Just to give a few examples.

> No - you wouldn't. But, then, the concept of "hotlining the entrant to
> a PSAP" refers to a procedure that isn't described by ECRIT. There's
> no "hotlining". The device knows it wants

Right, but I was saying it is important for the access network to recognize that the 'special' entry the MS wants to do is for emergency, not let the access network roll dices.
Of course hotlining procedures are not in scope of ECRIT, there is nothing emergency-specific besides installing the right filters (which by the way we also discuss in the draft - should we also drop this?).

Dirk

> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, Martin;
> Richard Barnes; Bernard Aboba
> SDOs set their own agendas; that's fair enough. They don't always want
> to consider how their architectures interwork with specifications
> defined by, say, the IETF. So perhaps, as you say, it's pointless.
> While ECRIT procedures are at the IP level and are intended to support
> clients that are connecting on IP via a routing device at the access,
> a "link technology SDO" may still persist with the assumption that
> it's the connecting device that negotiates procedures in an emergency
> scenario. Alternatively, they may consider the ECRIT model and decide
> to do something different. It is, as you say, up to them.
>
> Which, if I understand it, is about negotiating an IP context in what
> is also an "emergency context". Leaving aside my point above as to
> whether that's a generally effective facility for supporting emergency
> connectivity, there's also the question (which I may be unfairly be
> attributing to
> Richard) as to what value it is to the access to know that this
> connectivity has been granted in an "emergency context".
> No - you wouldn't. But, then, the concept of "hotlining the entrant to
> a PSAP" refers to a procedure that isn't described by ECRIT. There's
> no "hotlining". The device knows it wants to initiate an emergency
> call; it gets location from the LIS, gets the PSAP URI from LoST, and
> initiates a SIP session to the PSAP. The proposition of "hotlining"
> based on a layer 2 technology specific procedure is the sort of thing
> I refer to above. An access technology specific SDO may, for their own
> reasons, decide to define this sort of thing. I think they're talking
> about use cases that are orthogonal to what ECRIT is describing. ECRIT
> describes emergency procedures for the Internet, on IP, and
> independent of access technology.
>
> I guess the extent to which an SDO thinks these things are worth
> developing depends on the extent to which they think a) ECRIT is not a
> significant model or to which b) they think there are "emergency" use
> cases that are outside the Internet domain or to which c) there is
> some complementary subset of use cases for their link technology (e.g.
> WiFi phones in an enterprise environment with an "emergency" button
> that set up an emergency IP context and are hotlined to the enterprise
> softswitch that then does ECRIT procedures to the outside world). The
> SDO just needs to decide whether there is a benefit consistent with
> the effort in defining/implementing such functionality. I think it's
> good if their delegates are aware of ECRIT in making that decision.
>
> Cheers,
> Martin
>
> > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson,
> > Martin; Richard Barnes; Bernard Aboba
> > 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.
> What flag are you refering to? Up to now we were only discussing
> options to indicate emergency in EAP, which rather on top of layer-2
> than IP.
>
> > 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.
> > > 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
> > > is on others. I doubt that there's a reasonable assumption that
> > > the connecting device can necessarily provide an explicit
> > > "emergency intent" flag.
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of ext Dawson, Martin
> > > 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
> > > 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
> > >
> > > 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,
> > > 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.
> > >
> > > 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)
> > > It would seem that dealing with EAP is not within the domain of
> > > this work group.
> > >
> > > Brian
> > >
> > >
> > > >> regulatory environments where there are some lawyers who think
> > > >> it's
> > > required to
> > > >> support
> > > >> it in some environments.
> > > >

---

From: Richard Barnes <[email-masked]>
Date: Mon, 29 Mar 2010 20:23:01 -0400

Why is this an issue for open APs?  Priority?
--Richard

On Mar 29, 2010, at 8:17 PM, <[email-masked]> wrote:

> In an RSNA enabled wifi network you are not redirected to a portal  
> page, but rather authenticated (if you have the key) before getting  
> associated. If you do not know the key, you can't associate, and  
> can't send any 802.11 data packets to the AP. If there was an  
> indication included in the EAP Request, then the AP would know that  
> this STA is requesting association for emergency call purposes, and  
> may be able to give access to it even if the STA is not in posession  
> of the proper credentials (installing filters would still be  
> necessary).
>
> For open access wifi networks, the 802.11 specification has a  
> slightly different solution than the one suggested below: the AP may  
> be configured with multiple SSIDs, with one of them being dedicated  
> for emergency call purposes. This is then signalled in the beacon  
> frame. STAs willing to place an emergency call would first perform  
> an active scan, identify the proper SSID and associate (RSNA is not  
> supposed to be enabled).
>
> -- Gabor
>
>
> * Once connected to the access, users are generally "portal locked"  
> to a single web page that requires further authentication/payment to  
> proceed. The access may provide some additional "filters" that allow  
> routes to some subset of news/commercial websites as a "bonus".
>
> * In order to support unauthenticated/anonymous emergency calling at  
> this point, the hotspot would need to add the location service,  
> access to LoST, and a route to the relevant PSAP URI(s) to the  
> filter list.
>
> connecting device *could* have provided an indication that it wanted  
> the connection for the purpose an emergency call? I don't think  
> anything needs to be done differently. I don't, for example, think  
> there's any prioritization benefit. An "emergency" type query to the  
> LCP (HELD option), an emergency service lookup to LoST, and a SIP  
> session directed toward a PSAP URI are all things that could be  
> explicitly detected and given priority. Priority isn't an end-goal  
> in itself in any case. The end goal is reliability and response time  
> for these emergency related services. The access provider may need  
> to ensure some service level there. They can do that without needing  
> to roll dice. And, given they can neither rely on devices to provide  
> an emergency indication nor trust that indication if they do, they  
> are likely better off providing the necessary service level for  
> emergency procedures independently of the device's broadc
>   asted intentions.
>
> Let me say that I think the draft is great; it crystallizes a lot of  
> issues. I just think the section on EAP isn't necessary; it doesn't  
> describe a generally applicable solution and its presence is likely  
> to cause confusion as to its significance. In answer to your  
> question; no, I don't suggest dropping the discussion on filters. I  
> think that's a fundamental aspect; I think it's orthogonal to the  
> concept of an "emergency intent indicator".
>
> Cheers,
> Martin
>
>
>
> recognize that the 'special' entry the MS wants to do is for  
> emergency, not let the access network roll dices.
> nothing emergency-specific besides installing the right filters  
> (which by the way we also discuss in the draft - should we also drop  
> this?).
>
> Dirk
>
>>>> Behalf Of Brian Rosen

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 29 Mar 2010 23:41:17 -0700 (PDT)

Actually, in an RSNA you authenticate _after_ you associate. In fact,
you authenticate after you "authenticate". The process is this:

   - STA discovers AP through active probing or seeing beacons
   - STA to AP: "authenticate me!"
   - AP to STA: "you're authenticated"
   - STA to AP: "associate me!"
   - AP to STA: "you're associated"

and then begins the exchange of data frames with an ethertype indicating
EAPOL to do the actual authentication. The 802.1X state machine says that
all frames, except EAPOL frames, must be dropped prior to the completion
of 802.1X.

  You're right that an AP can advertise different SSIDs, and have a
non-RSNA-enabled one mapped to some special VLAN that is used solely for
emergency access-- associate here and all you get is the E-911 call center.

  Dan.

On Mon, March 29, 2010 5:17 pm, [email-masked] wrote:
> In an RSNA enabled wifi network you are not redirected to a portal page,
> but rather authenticated (if you have the key) before getting associated.
> If you do not know the key, you can't associate, and can't send any 802.11
> data packets to the AP. If there was an indication included in the EAP
> Request, then the AP would know that this STA is requesting association
> for emergency call purposes, and may be able to give access to it even if
> the STA is not in posession of the proper credentials (installing filters
> would still be necessary).
>
> For open access wifi networks, the 802.11 specification has a slightly
> different solution than the one suggested below: the AP may be configured
> with multiple SSIDs, with one of them being dedicated for emergency call
> purposes. This is then signalled in the beacon frame. STAs willing to
> place an emergency call would first perform an active scan, identify the
> proper SSID and associate (RSNA is not supposed to be enabled).
>
> -- Gabor
>
>
> * Once connected to the access, users are generally "portal locked" to a
> single web page that requires further authentication/payment to proceed.
> The access may provide some additional "filters" that allow routes to some
> subset of news/commercial websites as a "bonus".
>
> * In order to support unauthenticated/anonymous emergency calling at this
> point, the hotspot would need to add the location service, access to LoST,
> and a route to the relevant PSAP URI(s) to the filter list.
>
> The question I raise is what would be done differently if the connecting
> device *could* have provided an indication that it wanted the connection
> for the purpose an emergency call? I don't think anything needs to be done
> differently. I don't, for example, think there's any prioritization
> benefit. An "emergency" type query to the LCP (HELD option), an emergency
> service lookup to LoST, and a SIP session directed toward a PSAP URI are
> all things that could be explicitly detected and given priority. Priority
> isn't an end-goal in itself in any case. The end goal is reliability and
> response time for these emergency related services. The access provider
> may need to ensure some service level there. They can do that without
> needing to roll dice. And, given they can neither rely on devices to
> provide an emergency indication nor trust that indication if they do, they
> are likely better off providing the necessary service level for emergency
> procedures independently of the device's broadc
>    asted intentions.
>
> describe a generally applicable solution and its presence is likely to
> cause confusion as to its significance. In answer to your question; no, I
> don't suggest dropping the discussion on filters. I think that's a
> fundamental aspect; I think it's orthogonal to the concept of an
> "emergency intent indicator".
>
> Cheers,
> Martin
>
>
>
> Of course hotlining procedures are not in scope of ECRIT, there is nothing
> emergency-specific besides installing the right filters (which by the way
> we also discuss in the draft - should we also drop this?).
>
> Dirk
>
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>