[Geopriv] Re: Strawman Proposal

[Hannes Tschofenig <[e-mail]>]

Hi James,

Winterbottom, James wrote:
> 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.
>
>   
If operators don't want to make location information available to the 
end host then location signing is not helpful for them either.
I also know that the same operators want to stick with the IMS approach 
where they neither need the LCP nor the location signing approach.

>   
>> * 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.

I don't know what the last part of the sentence means.
>  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.
>   
What is the re-query in this context?

The PSAP fetches the location for the first time (given that only coarse 
grained  location information is available for routing). Nothing else is 
needed. That's already far more than they have today. ;

>   
>> 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
>   
I agree it is useful to provided authenticated emergency calls in all 
cases.
Mechanisms like P-Asserted-ID or SIP Identity will be useful in many 
other cases, not just for emergency service calls. Being able to trace a 
caller back to its real identity is really, really helpful. Location 
signing cannot provide you with this functionality.

>  
>   
>> 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.

I don't think that this is true. I have heard from cases where the 
location information is only retrieved when absolutely needed.


>  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.
>   

Ciao
Hannes

> 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