Subject: RE: [sipping] comment on draft-polk-sipping-location-requirements -01.txt

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 16 Dec 2003 10:52:54 -0500

I think you leaped a little too far.

You correctly point out that abuse is an issue, and that 
verification is a requirement.  This is actually a fairly 
complex issue.  For example, it is not uncommon for there 
to be more than one way to refer to an address.  In most 
existing emergency systems, there is an "authenticated"
address database.  In North America, this is called the 
"Master Street Address Guide".  It's not sufficient to 
report an address, it has to be an address in the MSAG.  
There are extensive procedures in place to make sure the 
MSAG is accurate, and that addresses reported are in it.
To be sure, it's never completely accurate, and call 
centers take calls that report addresses not in the MSAG, 
but they try hard.

I believe that we need to have a way to authenticate an 
address in such a way that it can be determined to be 
equivalent to be in the MSAG.

But, you also raised another issue, which is deliberate 
falsification of location.  You proposed that for this 
purpose, the network be able to assert a location.  You point 
out that there are legitimate reasons why they could be 
different with the phone's location correct, and the proxy's 
incorrect.

I believe that there is no reasonable way for the emergency 
center to differentiate.  Even if they asked, verbally, they 
would not get any closer to the "truth" (the VPN customer 
would say the phone is right, but so would the prankster).  
I would hate to be in the position of trying to figure out 
which was more likely.  Sending responders to both locations 
would get the problem you posed (risk to responders, and 
non-availability of people/equipment).  I conclude that there
the proposed solution is no better than living with the 
problem.

You will note that you have to have a corruptible UA to make 
this happen.  Such a thing is pretty easy, to be sure (open 
source soft client for example).  However, that also makes it 
trivial to bypass any troublesome proxies.  The emergency centers 
know that they will get VoIP calls from the open Internet 
(no proxy) as well as calls from known service providers.  
They may be more suspicious of calls from random places on the 
Internet, but they are likely to take them.

I've wondered if there is some value in a single bit of 
information from the service provider/proxy, which is that it's 
suspicious of the location.  With that bit, the emergency center 
is at least alerted that there is something "odd".  In a VPN 
situation, the caller could, if asked, explain that she is using 
her employers phone system from the Starbucks.  The prankster 
would still lie of course.  Also note that a prankster is not 
a legitimate call; the location the network could report is not 
useful; that it is different from that reported by the UA is 
the only useful information.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2003 8:56 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [sipping] comment on
> draft-polk-sipping-location-requirements-01.txt
> 
> 
> I think there is a mix up here.
> 
> Location is needed for two reasons:
> Firstly to determine the correct emergency answering operator.
> Secondly to determine where to send the emergency response.
> 
> If we don't get the first one right then there is no chance 
> of even being close on the second.
> 
> But there is another requirement: avoiding abuse.
> 
> It is well known that calling the fire brigade and claiming 
> there is a fire at the cremetorium is a supposedly funny gag 
> that puts lives at risk (as the emergency services must respond).
> Security is important in authorisation and location 
> determination to ensure that the information given is consistent.
> 
> There are times when the terminal knows that it is not where 
> the Proxy thinks it is, but verification by the first proxy 
> is an important factor in verifying that this looks as though 
> it is a genuine emergency call.
> 
> Hence I conclude that the Proxy SHOULD be allowed to insert 
> location information (suitably protected) in order to assist 
> in the verification process. Also the teminal needs to be 
> able to indicate that the proxy is probably wrong (e.g. 
> connected via a secure VPN tunnel to corporate intranet).
> 
> Privacy is important to outsiders but not to a genuine 
> emergency caller wanting to share their location with an 
> emergency operator (clearly a trusted entity), and there are 
> advantages in having a proxy verify that the information is 
> correct. This provides a real improvement to response times 
> (in the UK) by the emergency services (fire police ambulance etc.).
> 
> Dick Knight
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Rosen, Brian
> Sent: 12 December 2003 13:03
> To: 'PROUVOST Sébastien FTRD/DAC/ISS'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [sipping] comment on
> draft-polk-sipping-location-requirements-01.txt
> 
> 
> I think that the issue is one of privacy control.  If some
> intermediary puts your location on the message without your
> consent, there is a significant breach of privacy.
> 
> The emergency case is somewhat different, and we are looking
> into how best to accommodate it.  In general, our approach
> is to get the UA to know its location and report it with
> the call.  We understand the issue of authentication of
> location, and will need to assure that the location is accurate
> when a carrier knows what it is.   If the location is
> provided to the UA, and it chooses to NOT send it, I believe
> he should be allowed to do so.  There are several ways the UA
> could learn its location from some other entity.  One of them
> is DHCP (for a non-mobile UA). 
> 
> Do you see any problem with that approach?
> 
> Brian
> 
> > -----Original Message-----
> > From: PROUVOST Sébastien FTRD/DAC/ISS
> > [mailto:[email-masked]]
> > Sent: Monday, December 08, 2003 10:10 AM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: [sipping] comment on
> > draft-polk-sipping-location-requirements-01.txt
> > 
> > 
> > Hi,
> > 
> > I fully support the idea of having location information 
> > conveyed in SIP.
> > 
> > However, I fail to see in the draft a requirement for a proxy 
> > to be able to insert the location object on behalf of the UA. 
> > It is likely that in some cases terminals may not have this 
> > information. In some architectures, an outbound proxy may be 
> > able to retrieve this information (eg. Through a MIDCOM or 
> > COPS interface with an entity in the transport plane) and it 
> > is useful to allow such an outbound proxy to insert this 
> > location object.  
> > 
> > As stated in requirement E-3 regarding emergency calls, it 
> > may be a regulatory obligation for an operator to make this 
> > location information available to certain users. Operators 
> > may therefore be mandated to have this information inserted 
> > by proxies if the terminal does not insert it.
> > 
> > Regards,
> > 
> > Sébastien Prouvost
> > France Télécom R&D/DAC/CAR
> > http://www.francetelecom.com/rd
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 Dec 2003 11:36:12 -0500

To avoid further repeating discussions: We do need to design things so 
that a proxy can, in real-time, provide the 911-calling UA with its 
estimate of the location, in particular if the INVITE does not contain 
this location. This does not necessarily imply that the proxy has to 
insert the location into request; it could, for example, return it as 
part of a redirect response.

This mechanism allows the UA to (theoretically) inspect the location, 
thus increasing user control over his or her information.

However, it is unclear to me why such control does not treat me as 
mature enough to provide explicit consent - "please insert location 
object". (The UI issues of obtaining consent are similar whether the 
location object is reflected or included.)

This model comes at a cost, namely requiring UA upgrades and additional 
round-trip times over a potentially slow air interface. (If the location 
object is signed by the proxy, it can be quite large, so the additional 
delay could reach a second or two.)

This same cost makes it unrealistic to assume that the proxy or some 
other entity will continuously update the mobile with its location. The 
911 location requirements would require updates at least every second if 
the mobile is moving at highway speeds.

A secondary disadvantage is that the prankster can remove the location 
information; more relevantly, a proxy probably has to somehow 
distinguish that it tried to redirect with location information, but got 
the same call back later, still without location information (since the 
UA was buggy or old) and then has to forward the INVITE, without 
location information.

In general, unless you require proxy operators to be certified by a 
single government agency, even a signed location object, reflected or 
inserted, tells the PSAP very little. The signature can be from 
mafia-r-us.com, after all.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Dec 2003 00:43:23 -0500

inline.

> thus increasing user control over his or her information.

In the case of 911, though, does this matter? Calling 911 does imply 
that you have waived your right to privacy. Furthermore, I doubt that, 
while in the process of having a heart attack and having managed to 
dial 911, I will really want to inspect the location information 
provided by my proxy. A 911 call is exactly the kind of case where you 
dont want user interaction for the call to proceed.

> UA was buggy or old) and then has to forward the INVITE, without 

You have quoted several disadvantages to the redirect model, but no 
advantages over the proxy-inserted model. I really don't see what is 
lost, but see that a lot can potentially be gained. Indeed, I see no 
problem with having the proxy insert location inforamtion in addition 
to that provided by the device. This would allow the emergency call 
center, in many cases, to get verification of accuracy of the address 
when the device has more accurate data than the network; they would 
see that the network indicated a location of "New Jersey", and the 
handset indicated a location of "600 Lanidex Plaza, Parsippany, NJ", 
giving some confidence that the handset-provided location is not 
falsified. Havign vastly different addresses would also send a signal 
to the emergency operator that they really need to verify the address.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Dec 2003 09:48:24 -0500

> while in the process of having a heart attack and having managed to dial 
> 911, I will really want to inspect the location information provided by 
> my proxy. A 911 call is exactly the kind of case where you dont want 
> user interaction for the call to proceed.

I fully agree; I was simply trying to represent the motivation leading 
to the end-system-control argument by some in this discussion. Maybe I 
should just let them speak for themselves.

> problem with having the proxy insert location inforamtion in addition to 
> that provided by the device. This would allow the emergency call center, 
> in many cases, to get verification of accuracy of the address when the 
> device has more accurate data than the network; they would see that the 
> network indicated a location of "New Jersey", and the handset indicated 
> a location of "600 Lanidex Plaza, Parsippany, NJ", giving some 
> confidence that the handset-provided location is not falsified. Havign 
> vastly different addresses would also send a signal to the emergency 
> operator that they really need to verify the address.

No disagreement.