ecrit@ietf.org
[Top] [All Lists]

Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks o

Subject: Re: [Ecrit] emergency access and EAP-TLS and denial of serviceattacks on the emergency.com domain
From: "Kroeselberg, Dirk (NSN - DE/Munich)"
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

> -----Original Message-----
> From: ext Dawson, Martin [mailto:Martin.Dawson@xxxxxxxxxx] 
> Sent: Wednesday, March 24, 2010 5:42 AM
> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; 
> Thomson, Martin; Richard Barnes; Bernard Aboba
> Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> 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:dirk.kroeselberg@xxxxxxx] 
> Sent: Wednesday, 24 March 2010 2:12 PM
> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard 
> Barnes; Bernard Aboba
> Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> 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:Martin.Dawson@xxxxxxxxxx] 
> > Sent: Wednesday, March 24, 2010 2:15 AM
> > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; 
> > Thomson, Martin; Richard Barnes; Bernard Aboba
> > Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> > 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:dirk.kroeselberg@xxxxxxx] 
> > Sent: Wednesday, 24 March 2010 10:14 AM
> > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard 
> > Barnes; Bernard Aboba
> > Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> > 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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] 
> > > On Behalf Of ext Dawson, Martin
> > > Sent: Tuesday, March 23, 2010 11:44 PM
> > > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
> > > Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> > > 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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] 
> > > On Behalf Of Brian Rosen
> > > Sent: Wednesday, 24 March 2010 8:29 AM
> > > To: Thomson, Martin; Richard Barnes; Bernard Aboba
> > > Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> > > 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" 
> > > <Martin.Thomson@xxxxxxxxxx> 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
> > > Ecrit@xxxxxxxx
> > > https://www.ietf.org/mailman/listinfo/ecrit
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@xxxxxxxx
> > > https://www.ietf.org/mailman/listinfo/ecrit
> > > 
> > 
> 
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ecrit

<Prev in Thread] Current Thread [Next in Thread>