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 > -----Original Message----- > From: ext Dawson, Martin [mailto:[email protected]] > Sent: Thursday, March 25, 2010 3:16 AM > To: Kroeselberg, Dirk (NSN - DE/Munich) > Cc: [email protected]; [email protected] > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > of serviceattacks on the emergency.com domain) > > 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 > > > > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) > [mailto:[email protected]] > Sent: Thursday, 25 March 2010 2:46 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) > > > 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 > > > -----Original Message----- > > From: ext Dawson, Martin [mailto:[email protected]] > > Sent: Wednesday, March 24, 2010 5:42 AM > > To: Kroeselberg, Dirk (NSN - DE/Munich); 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) > > > > > > Hi Dirk, > > > > > I do not see a value in such recommendation from IETF would be. > > > 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. > > > > > 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. > > > > 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? > > > > > 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? > > > > 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 protected]] > > Sent: Wednesday, 24 March 2010 2:12 PM > > 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) > > > > see inline. > > > > Dirk > > > > > -----Original Message----- > > > From: ext Dawson, Martin [mailto:[email protected]] > > > Sent: Wednesday, March 24, 2010 2:15 AM > > > To: Kroeselberg, Dirk (NSN - DE/Munich); 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) > > > > > > 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? > > > > > > > > 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 > > > > > > > > > > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
