Subject: RE: [Ecrit] RE: [Ecru] requirements

From: "Ciesla, Larry" <[email-masked]>
Date: Thu, 24 Mar 2005 09:51:35 -0600

It may help to understand three critical things happen when someone
dials 911, and I believe most in public safety would agree that the
criticality of each of these is in the order I show below:

1. A voice connection is established with a 9-1-1 call-taker responsible
for emergency calls in the physical region in which the caller is
located.  The ability to communicate verbally is obviously the most
critical aspect of dialing 911.
2. The location of the caller is displayed to the 9-1-1 call-taker.
Call-takers are trained to always verify that the location presented is,
in fact, the location of the emergency.  
3. The telephone number of the phone that originated the call is
presented to the call-taker.  The latter is only used if the caller
hangs up and the 9-1-1 call-taker needs to call back.

I'm not sure that in the context of a DoS attack, attempting to call
caller's back would only make the problem worse.  The thing is, unlike a
DoS attack on some computer where millions of attempts are necessary to
render the computer useless, most PSAPs have two or three 9-1-1 call
takers.  By comparison, a tiny number of attacks on a PSAP could take it
out of service.  I sure hope the collective intelligence of all the
smart people trying to figure this out can find a way to prevent this.

Larry Ciesla
Senior Technical Officer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Medhavi Bhatia
> Sent: Wednesday, March 23, 2005 1:25 PM
> To: 'Byron Smith'; [email-masked]
> Subject: RE: [Ecrit] RE: [Ecru] requirements
> 
> I saw some discussion on one of the ETSI lists on requirements and
work on
> handling calls from unauthorized callers (without valid USIM). I think
> they
> are looking at it as well. Your point of having to call the caller
back is
> important to prevent something like a DoS attack on the emergency
service
> provider. Will the ability to call the caller back (which means that
the
> wireless SP should be able to call a phone not on its network...) and
> locate
> the origination be enough to deter attacks that authentication may not
be
> necessary ? Not sure how this can be done.
> 
> 
> -Medhavi.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of
> Byron Smith
> > Sent: Wednesday, March 23, 2005 12:35 PM
> > To: [email-masked]
> > Subject: [Ecrit] RE: [Ecru] requirements
> >
> > Actually many/most unsubscribed wireline phones may NOT dial 911.
State
> law
> > may apply.  It depends on the policy (and sometimes, the equipment)
of
> the
> > local service provider. There are many problems with unsubscribed
> wireline
> > 911, including incorrect routing and no associated ALI record.
> >
> > The FCC requires unsubscribed wireless phones be able to dial 911.
> However,
> > this is also problematic, because, in general, the PSAP cannot call
back
> the
> > unsubscribed phone, and because there may be no way, in general, to
> trace
> > the "owner" of the phone.  Several PSAPs have been the victim of
> > multiple/recurring "crank" 911 calls from unsubscribed (anonymous)
> wireless
> > phones. It can be a serious problem.
> >
> > Byron
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
Behalf
> Of
> > > Ciesla, Larry
> > > Sent: Wednesday, March 23, 2005 11:39 AM
> > > To: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: [Ecrit] requirements
> > >
> > >
> > > In fact, a user does not even need paid phone service for 911 to
> > > work today. Both wireline and wireless phones will allow 911 to
> > > work for unsubscribed phones.  Perhaps the notion of
> > > authorization should be viewed in the context that the entity
> > > assigning location information to a phone should be authorized to
do
> so.
> > >
> > > Regards
> > >
> > > Larry Ciesla
> > >
> > >
> > >
> > > ***This message has been sent via the Intrado Wireless
> > > Information Network.***
> > >
> > > -----Original Message-----
> > > From: [email-masked] <[email-masked]>
> > > To: Ken Carlberg <[email-masked]>; 'Tschofenig Hannes'
> > > <[email-masked]>; [email-masked] <[email-masked]>
> > > Sent: Wed Mar 23 09:28:10 2005
> > > Subject: RE: [Ecrit] requirements
> > >
> > > All -
> > >
> > > I think the basic question being asked deals with two (or more)
> different
> > > flavors under the umbrella of Emergency Services. Two existing
> > > examples are:
> > >
> > >   o B/E911 in the US - does not require that the "caller" be
> > > authorized, or
> > > even identified (most 911 systems today are required to provide
> anonymous
> > > access);
> > >
> > >   o GETS (Government Emergency Telecommunications Service) in the
> > > US, which
> > > can only be used by authorized users - uses PIN mechanism
> > > something like a
> > > calling card to allow the caller to authenticate.
> > >
> > > I think the original e-mail was asking for a specific requirement
> > > for ecrit
> > > (911 service domain) stating that "caller" MUST NOT be required to
be
> > > pre-authorized or to have to authenticate in order to place an
> emergency
> > > service (e.g. 911-type) call.
> > >
> > > John
> > >
> > > ------------------------
> > > John Rosenberg
> > > Lucent Technologies
> > > LSS Core Product Mgmt
> > > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt
> > > 630-713-7162
> > > [email-masked]
> > >
> > >
> > > At 10:15 AM 3/23/2005, Ken Carlberg wrote:
> > >  >> you might remember the presentation by james about validation
> > > of location
> > >  >> information. he pointed out that access network provides
location
> > >  >> information to the end host in such a way that the emergency
> response
> > > center
> > >  >> is able to verify that a "trusted" access network created the
> > > object and
> > >  >> (maybe that this network is indeed reponsible for the area).
> > >  >
> > >  >James may correct me, but I would say that the scenario you
paint
> above
> > >  >is one of authentication and integrity in the "validation of
> location
> > >  >information".  I would not consider that a case of
authorization,
> since
> > >  >I bind that security component with usage of a service.  we may
have
> to
> > >  >chalk this up as a case of agreeing to disagree.
> > >  >
> > >  >> we had some further discussions about this issue in the
> > > geopriv working
> > >  >> group. i also consider this as part of the authorization
decision.
> > >  >> there are still a number of issues that need to be
investigated
> and
> > >  >> discussed (and i am not sure that i understood all aspects;
> > >  >> the same is probably true for other folks as well).
> > >  >
> > >  >I have not been following geopriv as closely as I should have,
> > > so I can't
> > >  >comment on this.
> > >  >
> > >  >> there will not be a 'must be authenticated' and 'must be
> authorized'
> > >  >> requirement for 911/etc. calls (what we have heard so far in
the
> > >  >> discussions).
> > >  >
> > >  >well, my personal feeling is that users and information should
be
> > >  >authenticated to offer a measure confidence to others as to the
> > >  >validity of the user and/or the information (eg, location info)
> > >  >being provided.
> > >  >
> > >  >> we should also discuss what the meaning of the authorization
> decision
> > > in the
> > >  >> context you mention (rfc 2906) is. do you think about 'user x
> > > is subscribed
> > >  >> i.e. was successfully authenticated' or 'user x has
> > > sufficient funds' or
> > >  >> 'user x is within a specific geographical area' etc.
> > >  >>
> > >  >> i think that most people do not make an assumption about
> > > authorization in
> > >  >> this particular area. i would like to know what type of
> > > authorization the
> > >  >> ieprep folks consider.
> > >  >
> > >  >in my view, you are mixing components of security.  a service is
> > >  >potentialy authorized and information in potentially
authenticated
> > >  >-- I say potentially because the security portion may not be
> deployed.
> > >  >
> > >  >I'm probably being very picky in my terminology, but I would say
> that
> > >  >ieprep does not consider a "type of authentication" because that
> would
> > >  >correlate to a solution, which is not in the current charter of
> ieprep.
> > >  >
> > >  >rfc-3689 from ieprep provides some general requirements with
respect
> > >  >to authorization/integrity/authentication, but the rfc is only a
> > >  >baseline starting point from which more specific requirements
can
> > >  >be defined within that group.  it can be debated how effective
this
> > >  >approach was, but that was the direction we took at the time.
> > >  >
> > >  >-ken
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >_______________________________________________
> > >  >Ecrit mailing list
> > >  >[email-masked]
> > >  >https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Anti-Virus.
> > > Version: 7.0.308 / Virus Database: 266.8.0 - Release Date:
3/21/2005
> > >
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit