Subject: RE: [Ecrit] Emergency [mapping still needed?]

From: "McCalmont, Patti" <[email-masked]>
Date: Mon, 12 Sep 2005 13:19:19 -0500

Below,

Patti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Monday, September 12, 2005 9:37 AM
To: 'James M. Polk'; 'Winterbottom, James'; 'Ted Hardie'; 'ECRIT'
Subject: RE: [Ecrit] Emergency [mapping still needed?]

I think that the idea that a phone gets its own location, recognizes
emergency calls itself, and does its own mapping is a Really Good Idea.
It
means fewer things have to work to get an emergency call through.

PLM - Now you have all the security issues with passing location through
the network. You also have the issues around how to ensure the location
is valid and hasn't been altered. For a very long time there will be
phones out there that aren't capable of storing their own location, yet
alone doing the mapping and addressing security. The hardest part to any
requirements is to support the existing infrastructure along with what
is coming out. I agree that if we all could just toss in all the old
technology and could start out with a brand new slate that what Brian
states is correct. HOWEVER.....that's not the real world. Location by
reference seems a better path - IMO and HELD looks like it is attempting
to address the new and old world.

<SNIP>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of
James M. Polk
Sent: Sunday, September 11, 2005 6:50 PM
To: Winterbottom, James; Ted Hardie; ECRIT
Subject: RE: [Ecrit] Emergency [mapping still needed?]

At 06:36 PM 9/8/2005 -0500, Winterbottom, James wrote:

>All this aside, I think that there are economies of scale, and
>functionality reasons why including a gateway such an ESRP are
>desirable, but these are more implementation details. Somewhere,
>something has to have sufficient knowledge to use location to route the
>signal to the next hop.

Not necessarily.

If the UA has the URI of the PSAP, no further mapping operation is 
necessary, and you're done, point-to-point.

How the UA got the URI *could* be from Layer 2/3 (DHCP) or a protocol at

Layer 7, but prior to the emergency call. Either way, the mapping
operation 
could already be done when the call is started.

>Cheers
>James

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
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

---

From: John Schnizlein <[email-masked]>
Date: Mon, 12 Sep 2005 15:32:59 -0400

Let's take these arguments one at a time:

1) "security issues with passing location through the network"
At some point, the location information has to get from the user's 
access network to the emergency provider.  If the user's phone includes 
its location in the call setup, it has exactly the same "security 
issues" as the emergency call - no more.

2) "ensure the location is valid and hasn't been altered"
When examining the threat of altered location information, one has to 
consider which actors have what motivations.  It seems to me that the 
actor least interested in altering location information is the user who 
is seeking emergency service.    Consider what the emergency responder 
would do if the caller is recorded saying he/she is at a location other 
than where the system reports - would they not respond to that 
location?  I don't think so; the legal liability is too great.

The point that someone not seeking emergency service might make a 
fraudulent call is true today and not solvable in the general case by 
anything in the call process.  It would be nice if the 
location-indicating function of VoIP could eliminate the existing 
nuisance of bogus emergency calls, but nice is not the same as 
necessary.

3) "For a very long time there will be phones out there that aren't 
capable of storing their own location"
My experience with the rapid rate at which cell phones are voluntarily 
replaced by their owners suggests that this might be a mistaken 
forecast.  I will keep my fallback wireline phone around, but it has 
the existing location mechanism.  What fraction of the expected 
eventual deployment of IP phones do you think is now deployed?  
Wouldn't it be easier to provide some work-around for those legacy 
location-challenged phones than to make the entire system brittle 
because it is unnecessarily complex?

What fraction of the now-deployed IP phones include the process of 
obtaining a HELD-type reference and including that in their emergency 
call setup?

My alternative forecast is that widespread adoption of GPS and Galileo 
technology will make it likely that phones and other devices will have 
their own locations.  The economics of large-scale microelectronics 
suggest that it will not take very long before the cost of including 
location capability will be such a small fraction of the price of the 
phone that it will be included as routinely as personal computers now 
include ethernet interfaces.  http://www.useu.be/Galileo/

John

On Sep 12, 2005, at 2:19 PM, McCalmont, Patti wrote:
> From: [email-masked]  On Behalf Of Brian Rosen
>> It means fewer things have to work to get an emergency call through.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Sep 2005 07:07:59 -0400

You have security issues no matter what; this doesn't change them in any
significant way.  The endpoint is providing some kind of data, be it an
actual location or something that can be exchanged for a location, and there
is a variety of attacks on all forms of this kind of data.

The location used for mapping can be signed by the access network, as has
been discussed, and it can have a time stamp, which helps a little in replay
attacks.  The PSAP can verify that the location matches the mapping.  There
are no new issues.

I am also in agreement with John that while we DO wish to put up reasonable
defenses against location forgery, they are unlikely to be foolproof, we
have the problem today in various forms, and making the system work reliably
in disasters is more important than preventing location forgery.  Simple
systems ALWAYS work better than complex systems, and it's often the case
that if you make the security systems too complex, they reduce the overall
reliability of the system.

I am reminded of several times where PSAP folks have insisted that we MUST
have validated location and we MUST have authorization and we MUST to this,
and we MUST do that, and I ask them what happens if they get a call without
any of that.  The answer is that they take the call, and go ask the
questions of what failed later.

I take from that that we should provide robust security mechanisms, but that
if they fail, we send the calls anyway.

Brian

-----Original Message-----
From: McCalmont, Patti [mailto:[email-masked]] 
Sent: Monday, September 12, 2005 2:19 PM
To: [email-masked]; James M. Polk; ECRIT
Subject: RE: [Ecrit] Emergency [mapping still needed?]

Below,

Patti

-----Original Message-----

<SNIP>

-----Original Message-----

Not necessarily.

cheers,
James

                                 *******************

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 14 Sep 2005 11:47:00 -0400

Patti,

> 
> PLM - Now you have all the security issues with passing 
> location through the network. You also have the issues around 
> how to ensure the location is valid and hasn't been altered. 
> For a very long time there will be phones out there that 
> aren't capable of storing their own location, yet alone doing 
> the mapping and addressing security. The hardest part to any 
> requirements is to support the existing infrastructure along 
> with what is coming out. I agree that if we all could just 
> toss in all the old technology and could start out with a 
> brand new slate that what Brian states is correct. 
> HOWEVER.....that's not the real world. Location by reference 
> seems a better path - IMO and HELD looks like it is 
> attempting to address the new and old world.
> 

1) There is support for the 'old world' today, location by reference.  NENA
i2 is based on it.  There is no reason to expect that mechanism to
disappear.  'Old world' devices have constraints due to architecture, so?
Upgrade to a new device and lose constraints.

2) A large portion of 'toss in all the old technology' is simply a software
upgrade.  Not unsurmountable, it happens all the time.  For those that can't
upgrade a 'due to new emergency calling requirements, your device will not
be supported after ??? date' message to the customer is not unreasonable.

3) The current installed based is no more than a rounding error to the
forcasted number of devices.

IMO, support of installed devices gets way to high of a priority, it should
be a nice-to-have requirement.

-Marc-