[Geopriv] RE: Strawman Proposal

["Winterbottom, James" <[e-mail]>]

Hi Hannes,


> * We don't do Location Signing at all.
> * Access networks distribute location information to the end host at a
> granularity that allows location based routing (unsigned). For most
> countries this is in fact trivial.


[AJW] My discussions with carriers and infrastructure providers seems to
suggest that obtaining location information to provide to end hosts is
going to be far from trivial. When confronted with this hurdle I am not
so sure that adding signing is that much more work.


> * Access networks additionally provide a location-by-reference to the
> end host (if necessary and if they can do so)
> This reference is resolved by the PSAP for detailed location
information
> retrieval. The PSAP can therefore also authenticate the LIS and has
the
> information about the access network.

[AJW] It is not clear to me how I can use this approach to provide an
answering or priority policy for the PSAP. Do however agree that a
re-query mechanism as you suggest is useful where the PSAP wants
up-to-date or more accurate location information.

> 
> As Henning pointed out there is some value in authenticating the
> emergency caller (directly or indirectly). Why did nobody investigate
it
> since it also allows to get hold of the adversary? It might not look
so
> nice from crypto point of view but it would provide a lot of help.
> 

[AJW] It is not clear to me how authenticating millions of users and
their multitude of identity mechanisms is any less daunting than
providing accreditation to potentially thousands of access network
providers. But perhaps I am missing the point. That said, if you couple
this with signed location then you have the whole gamut. See location
dependability draft
http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability-
00
 
> 
> PS: I also believe that the PSAP operator would accept calls that
don't
> have any location attached to it. How many calls today have location
> information available? Do we have some statistics about it?
> 

[AJW] All emergency calls in the world have some degree of location
provided (inferred), though in some cases this may not be fantastically
accurate, country level. In the United States for wireline it is based
on the calling line ID, and either an ESRD (roughly representing a cell)
or an ESRK (representing a rough calling area) for wireless.

Perhaps, like some other working groups we need to make the distinction
between support and implement. I am asking that the requirements include
support for it, I think that implementation will be something that
jurisdictions have the option to do or not.

Cheers
James




> 
> Winterbottom, James wrote:
> > I have re-read Ted's email now several times, and it seems to
> > concentrate on being able to detect and potentially thwart denial of
> > service attacks. While this is one of the potential problem it is
not
> > the only one, and I don't see the kind of thing Ted is talking about
as
> > addressing the same problems that signatures will address.
> >
> > Further more I did not seem to me to provide a concrete way of doing
> > what Ted was suggesting. Precisely how will this be done?  Without
these
> > details it seems like smoke and mirrors and may not end up being
> > possible at all. But I don't discount it as helping.
> >
> > I don't see DoS as being the only source of attack, and certainly
don't
> > see signatures as the solution to the DoS problem. I do see
signatures
> > as providing a good way to potentially screen crank-calls and
avoiding
> > unnecessary use of public resources.
> >
> > The 4 requirements I am tabling are below.
> >
> > 1) The only calls that SHALL be directed to a PSAP are those calls
that
> > have been made by end-devices that are in the PSAP service
jurisdiction
> > at the time a call is made.
> >
> > 2) Any location used by routing services or subsequent dispatch
services
> > MUST unequivocally represent the physical position of the end-device
at
> > the time the location is proffered.
> >
> > 3) Any request for location made to a LIS MUST result in either an
> > error, or the current location of the target device being returned.
> >
> > 4) The source of the location information MUST be identifiable and
is
> > accountable for the accuracy of the information provided.
> >
> > Providing you try to meet these 4 requirements I am happy. Simply
saying
> > they can't be done and so they are not requirements, as has been
said in
> > the past, is not acceptable.
> >
> > Cheers
> > James
> >
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Marc Linsner [mailto:[e-mail]]
> >> Sent: Tuesday, 13 March 2007 2:50 AM
> >> To: Dawson, Martin
> >> Cc: 'GEOPRIV'
> >> Subject: RE: [Geopriv] NENA Requirements
> >>
> >> Martin,
> >>
> >>
> >>> I think all of the NENA requirements have been raised and
> >>> discussed - the latest concept to cause indigestion is
> >>> location signing.
> >>>
> >> You have requirements mixed up with solutions.  Signing location
> >>
> > objects
> >
> >> is
> >> a solution.  I believe Ted nailed the requirement.
> >>
> >> -Marc-
> >>
> >>
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/geopriv
> >>
> >
> >
------------------------------------------------------------------------
> ------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> >
------------------------------------------------------------------------
> ------------------------
> > [mf2]
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]


_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv