Re: crypto delay (Notes from Non-meeting)

I don't think that's a viable option. The location information is used
for two different things:

- selecting the appropriate emergency call center that handles a
particular geographic region (PSAP in the US);

- providing the emergency call center with user location information

Clearly, the first requires location information as part of the call
setup and cannot be deferred until later in the call.

> 
> I'll conceed the point that it's possible to have the location information
> come later than the call completion.  That is undesirable (because
> it is actually very interesting to route the call in the emergency center
> based on location, something not possible now), but it's concievable.
> It's also not a great way to deal with in in SIP - rather than simply
> shoving the location in the INVITE, we have to create a mid call dialog.
> That is also possible, if undesirable.
> 
> Brian

RE: crypto delay (Notes from Non-meeting)

Agreed!  With SIP, location information must be in call setup.  Even
Wireless Phase II has issues with this that they have not solved as the
location information lags call setup by several seconds.  In a WPII call,
the PSAP choice is made by simply sending the call to the PSAP that services
'most' of the territory covered by the tower the caller is using.  The PSAP
will then 'transfer' the caller to another PSAP if appropriate.  Not a
choice with SIP as users are not 'tower bound'.

Hmm, maybe we need one PSAP per country............

-Marc Linsner-

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs <at> cs.columbia.edu]
Sent: Wednesday, April 03, 2002 8:45 AM
To: Rosen, Brian
Cc: 'Andrew Daviel'; 'geopriv <at> mail.apps.ietf.org'
Subject: Re: crypto delay (Notes from Non-meeting)

I don't think that's a viable option. The location information is used
for two different things:

- selecting the appropriate emergency call center that handles a
particular geographic region (PSAP in the US);

- providing the emergency call center with user location information

Clearly, the first requires location information as part of the call
setup and cannot be deferred until later in the call.

Re: crypto delay (Notes from Non-meeting)

Marc Linsner wrote:
> 
> Agreed!  With SIP, location information must be in call setup.  Even
> Wireless Phase II has issues with this that they have not solved as the
> location information lags call setup by several seconds.  In a WPII call,
> the PSAP choice is made by simply sending the call to the PSAP that services
> 'most' of the territory covered by the tower the caller is using.  The PSAP
> will then 'transfer' the caller to another PSAP if appropriate.  Not a
> choice with SIP as users are not 'tower bound'.
> 
> Hmm, maybe we need one PSAP per country............
> 

Yes, I would suggest the IETF be charged with changing the division of
powers between the federal government, the states and localities in the
United States and other countries. This is our core expertise and since
we have an ample budget to finance such a transition, we should get
cracking on this immediately. We'll have to set aside a few million for
a global CA for emergency centers, but the term "unfunded mandate"
hasn't stopped real politicians, either. Would somebody please start by
writing an Internet Draft on how to reorganize the provision of
emergency services so that they better conform to our protocol ideas?

Re: crypto delay (Notes from Non-meeting)

On Wed, Apr 03, 2002 at 08:27:56AM -0500, Rosen, Brian wrote:
> > Acatually, I'm not sure whey we spend so much time discussing the
> > E911 scenarios, though I'm clearly guilty of doing so myself. 
> > The reaction
> > time thing just caught my eye.
> > 
> One of the "users", probably the first user, of the geopriv object
> is emergency calls in SIP.  The requirements for emergency calls at the
> top level are pretty straightforward, but are clearly subject to
> interpretation as you dig down. 

Perhaps this is a mistake?  I think that emergency calling is complex,
and I'm far more concerned about my non-emergency privacy.

(I do think there is a security concern, which is that if I send your
internet phone a hyperlink of the form  "img src=tel:sos" you may hand
out your location without the same meaning as actually dialling 911.
We likely can't cope with this at the protocol level, but should note
it in the security concerns section, and suggest that turning off
privacy preference should be based on user action...)

> Emergency callers have some expectation of privacy.  That expectation
> is presently pretty limited.  There is no harm in providing a higher
> level of privacy, provided that you don't screw something up.  Response
> time is one of those things that can be screwed up.  Phones, in general,
> have fairly puny processors.  SIP phones have beefier processors than
> first gen cell phones, and 3G cell phones have processors capable of
> non-trivial crypto, but I think we have to keep "fraction of a second 
> on embedded cpu" goals when we make crypto choices.  If we are forced
> to choose between increased security and increased response time on

Re: crypto delay (Notes from Non-meeting)

On Wed, Apr 03, 2002 at 02:04:28PM -0500, Richard Shockey wrote:
> A
> 
> >Perhaps this is a mistake?  I think that emergency calling is complex,
> >and I'm far more concerned about my non-emergency privacy.
> 
> Until its you that has the heart attack.

No, even then, I'm more concerned about my privacy outside of the
emergency.  Or are you suggesting that the risks of having my
insurance company know about my eating habits are sufficiently
worrisome that I should worry about the privacy risks of location
phones at all times, even when having the heart attack? ;)

> >I'm also interested in trying, and would like to throw out the
> >suggestion that we might specify a level of crypto which is secure,
> >and offer nothing on slower processors.  That would make sense if we
> >worry about roll-back attacks, and the ongoing cost of having weak
> >crypto in the system.
> 
> I'm more concerned that the needs of the emergency response system are not 
> impeded in any form I'm having the heart attack thank you very much 
> ..adding complexity to the task of getting a location object from Point A 
> to Point B is a "bad thing" tm.  KISS strikes me as a more interesting 
> foundation for protocol design.

By "offer nothing" I meant offer no security or privacy for the
location information, not no location information, such that we don't
get bogged down in figuring out what authorization scheme meets the
privacy requirement, the routing requirement, and the speed

Re: crypto delay (Notes from Non-meeting)

Re: crypto delay (Notes from Non-meeting)

Re: crypto delay (Notes from Non-meeting)

On Wed, Apr 03, 2002 at 02:13:01PM -0600, James M. Polk wrote:
> At 09:50 AM 4/3/2002 -0500, Adam Shostack wrote:
> >On Wed, Apr 03, 2002 at 08:27:56AM -0500, Rosen, Brian wrote:
> 
> >> >
> >> One of the "users", probably the first user, of the geopriv object
> >> is emergency calls in SIP. 
> >
> >Perhaps this is a mistake?  I think that emergency calling is complex,
> >and I'm far more concerned about my non-emergency privacy.
> 
> Are you suggesting we now are looking at two solutions (because you just broke
> the problem up into two problems)?

I'm suggesting that the emergency use problem may be really hard, and it
may be worth looking at the non-emergency use cases as first user.
Thats still a hard problem, and if we can solve it, we may learn
things that we can apply to the emergency problem.

> >I'm also interested in trying, and would like to throw out the
> >suggestion that we might specify a level of crypto which is secure,
> >and offer nothing on slower processors.
> 
> Now, how is a single protocol (which GEOPRIV is chartered to create) going to
> tell the power *and* load of each processor before determining that crypto is
> or isn't required? Or am I misreading your comment?

I think you're misreading my comment.  Brian suggested that we have to
accomodate the lowest power processors out there with geopriv.  I'm
suggesting that we might design a secure protocol, and if the device
can't accomodate it, too bad.  We can always find a smaller, slower
device, on which someone may reasonably want to run GEOPRIV (say those
Hitachi 1/2 mm chips); should we lower the security of everyone's
system to accomodate those small processors?

Adam

Re: crypto delay (Notes from Non-meeting)

This all has very little do with crypto processing. As the last few
messages tried to show, it's a matter of message exchanges and
reliability.

Emergency calls are probably the single most important reason that
people care about location; most everything else is somewhere between
toy and "nice to have". Basically saying "we'll figure out later if this
works, if not, well, you just have to wait a few years" is not an
acceptable answer, methinks.

The emergency call problem is actually pretty simple. It only gets to be
hard if you put artificial constraints on it that no real user much
cares about (as witnessed by real, existing systems).

Re: crypto delay (Notes from Non-meeting)

At 5:10 PM -0500 4/3/02, Henning Schulzrinne wrote:

>.....
>Emergency calls are probably the single most important reason that
>people care about location; most everything else is somewhere between
>toy and "nice to have".

I can't prove it, but I do not think this is correct.  Emergency 
calls are certainly going to be, initially, the main place where 
location is used in a "critical" manner.  But I doubt that 911/SOS 
location tracking will be the big market driver for these services -- 
I expect that the "nice to have" services will drive deployment of 
location capable devices, and the ability of the services to also 
help out in an emergency will either be a market or (in some places) 
regulatory requirement.

But, in any event, I'm not sure that it makes a key difference here. 
At the end of the day, we need to be able to support emergency 
location tracking while at the same time protect privacy in the "nice 
to have" contexts.  I do not think that the WG will have succeeded if 
we cannot achieve both goals (at least for devices that have a 
moderate amount of processing power).

John

--------------------------------------------------
John Morris // CDT // http://www.cdt.org/standards
--------------------------------------------------