Subject: [Sip] Re: Comment on draft-ietf-sip-location-conveyance-00

From: "James M. Polk" <[email-masked]>
Date: Thu, 07 Jul 2005 18:39:31 -0500

John

Sorry for hte late reply - I was on PTO. Comments below:

At 10:18 AM 6/29/2005 +0100, Elwell, John wrote:

>James, Brian,
>
>In section 9 (special provisions for emergency calls) it states:
>
>"In the case where the Proxy knows the location of the UAC and does not 
>detect the UAC's location information message body in the message (or 
>determines the LO is bad), the Proxy generates a new 4XX (Retry Location 
>Body) error message that includes a location information message body for 
>that UAC to include in the subsequent message.  The user agent MUST 
>include this message body in the subsequent emergency message."
>
>This places a new requirement on the UAC,

yes it does

>which will not be met by UACs that are not compliant to this document.

Yes, this is true for all extensions

>It seems emergency calls from such UACs will fail.

Emergency calls only route to the appropriate PSAP based on the location of 
the caller. This will not change. SIP has no concept of physical location. 
If my current UA dials tel:911, where will the INVITE go to? 911 is good 
here in Dallas, Texas - just as it is good in New York City. There is no 
area code (ever) indicating where a 911 call is from or to. So how does the 
Proxy receiving this 911 as a Request-URI know how to route the message? 
The answer is in multiple steps:

The INVITE first has to be identified as an emergency call - a Request-URI 
911 will do this inside the US (112 works inside Europe), or Henning's 
proposed "sos@..." will do this in the future as it progresses.

The second piece to this puzzle is providing the location of the UAC. This 
serves 2 purposes:

1) it provides the location of the UAC to now look for the appropriate PSAP 
in that geographic area (the ECRIT WG is working on defining that mapping 
protocol/means of a UAC's location to the appropriate PSAP Request-URI), and

2) Providing the lcoation in the INVITE to the PSAP will give the PSAP 
operator a location to dispatch first responders to.

Without location in the INVITE, how are either of these functions accomplished?

SIP currently cannot do either without an extension to the protocol.

While adding a certain message body type isn't technically an extension, it 
is a change in behavior of a UAC and a Proxy/intermediary (to look for the 
location message body).

Given the existing SIP rules stating message bodies cannot be added to a 
SIP message by a SIP Proxy Server, we're limited with what we can do.

If the Proxy knows the location of the UAC, it has to have a means of 
informing the UAC of this location. There are several ways to do this - the 
one chosen here is a new 425 Response code (which is an extension to SIP) 
that includes a message body of the UAC's location to be used in the 
subsequent INVITE by the UAC. The user will not know of this initial 
rejection, and the UAC will need to know to send a new INVITE with this 
message body included.

I could have put in a 3XX Response to do this, but chose not to.

I don't understand Dave Oran's comment about adding a Supported header 
(Location) since this document doesn't allow a by-reference header.

Does this answer your question?

>Regards,
>John

cheers,
James

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

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 08 Jul 2005 09:44:55 +0100

James,

(Replying also to your message to Sebastien)
I agree that in many environments the UAC will be the best or only place to
supply location information, in which case obviously one will need a UA
enhanced with the ability to provide location information when making an
emergency call.

However, there will be some environments (notably enterprise environments)
where the proxy has knowledge of UA location. Sending back a 4xx will work
fine if the UA supports this. However, the ability for the proxy to add
location information (in a header) when forwarding the request would be
useful in order to support existing UAs that do not have this enhancement.

John

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: 08 July 2005 00:40
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: Comment on draft-ietf-sip-location-conveyance-00
> 
> John
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 08 Jul 2005 13:40:16 -0500

John

>useful in order to support existing UAs that do not have this enhancement.

Ok, but can you solve this in a header:

- the Geopriv WG was chartered with mandating security and privacy of a 
endsystem's location information (RFC3963) - based on the rules established 
by a "rulemaker" (which can be the enduser, the domain administrator or the 
combination), and I do not know how this can be accomplished if location is 
shown in a header inserted without the user's knowledge or control.

SIP message headers are TLS or IPsec hop-by-hop encrypted at best (right?), 
and may not be encrypted at all even one hop away from the UAC, so how is 
the user's privacy concerns about their location information not being 
divulged addressed?

This is accomplished if location were placed in a message body - which 
cannot be added in transit by a Proxy. This draft provides a means for a 
Proxy to say "hey, you need a location body in that message, here, use 
<this one> in your subsequent message". This is the 425 (Retry Location 
Body) Response I have in the doc.

To give some history, I orignially had location in a new header, but was 
told it had to be moved to the body by the WG, the chairs and the ADs (at 
Vienna). This was based on Geopriv guidelines.

So, I'm not necessarily disagreeing with you that there may be cases in a 
header is better than in a body, but I don't know how to *not* violate the 
specifics or spirit of what Geopriv is doing. RFC3963 is pretty clear that 
privacy concerns need to always be taken into account when identity is 
conveyed.

Any suggestions?

cheers,
James

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 8 Jul 2005 15:25:06 -0400

> shown in a header inserted without the user's knowledge or control.

The rule-maker's ability to set policies is completely unrelated to the protocol means by which location information is embedded in messages. The entity that serves location information, ultimately, must be responsible for seeing that the rule-maker's policies are enforced. This can be accomplished if that entity has access to the user's policies and implements them, regardless of how location information is mechanically inserted into signaling.

> the user's privacy concerns about their location information not being 

If the location information is added by-reference in a header, then no privacy-impacting information will appear in the message itself. Entities that want the location information will have to dereference the artifact in the header, and in that deferencing process, as well as in the object yielded by dereferencing, policies can be enforced.

> Body) Response I have in the doc.

All that is true, but I'm not convinced that there aren't ways for a proxy server to associate location information with a request that don't involve this degree of client support, and which can still provide the necessary GEOPRIV protections. At a high level, I am also very sympathetic to Mr. Elwell's concern that there are likely to be environments where the proxy server (let's say the local layer-7 domain) knows your location information, even when the endpoint and even the access network does not. Worse, I fear there might be environments where the local layer-7 domain might not even want to tell endpoints what it knows about location information directly.

> Vienna). This was based on Geopriv guidelines.

Just putting the raw location information as a text field in a header without any of the protections mandated by GEOPRIV is not a good idea, I agree. Since a message body can contain a full GEOPRIV object, it is a better place to put location information by-value than a header. However, that doesn't necessarily mean that there aren't viable approaches to location conveyance that involve headers. Placing a reference to location information in a header, rather than the location information itself, would be an example.

> privacy concerns need to always be taken into account when identity is 

Use a reference.

Jon Peterson
NeuStar, Inc.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 11 Jul 2005 13:36:53 -0500

John

I'm not understanding your comment - but will comment enough (I hope) to 
tease its meaning out. You talk about a risk in divulging location 
information, and I'm wondering how location can be inserted into a SIP 
message first.

A comment on the former (divulging):

The risk of divulging location is still a privacy choice today in the US. 
You can choose in some jurisdictions to not reveal your location even when 
dialing 911 in the PSTN. I would never do that, but it's possible. So, in 
my estimation, a similar local law will be addressing divulging location 
information over VoIP in that same jurisdiction - if the current law 
doesn't.  What do we do about this? Ignore it, or build into the protocol a 
means for obeying this knowledge law that will be imposed on vendors 
selling into that jurisdiction?

Now to the latter topic (location insertion in SIP messages):

SIP Servers (other than versions of B2BUAs) cannot insert a message body of 
any kind today according to RFC 3261 (agreed?). Recent discussions within 
the WG has this stipulation continuing.

So, in order to meet what you want, this server will need to add location 
as a SIP header. Which one? I don't believe one exists today that could 
satisfy this request/requirement. That's ok. This ID can invent one if 
necessary. Say the location header of the form:

         Location: <something>

where <something> is one of 4 choices. It is either :

1) a predetermined coordinate format like GPS (including a datum value)
2) a predetermined civic address format (with some indication if this is a 
postal address, a legal address or a billing address),
3) it is a freeform open string in cleartext,
4) or it is a URL to a reference on a server

#1 above is like the text version of RFC3825 or GPS
#2 above is like Henning's civic ID at
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-06.txt
but will be more difficult in format in have
#3 above is what it says - freeform cleartext like a token
#4 above is a URL to a record on a server that has potentially all format 
versions of location and provides the ability to challenge the requestor 
for credentials before divulging the location of the UAC.

BTW - you don't want the challenge in #4 to fail giving location out in a 
911 call for call routing or responder dispatch.

#4 above could also be a very long header-value (>100 characters), if that 
matters

One issue I have with option#4 above is that this means everytime I (for 
example) want to provide my location to someone else, I have to give this 
URL-based header out, or believe my SP will (because my UA doesn't know 
how). This is a means for the owner of the server the URL lives on to 
charge for that revelation of information, kinda like a dip into a PSTN 
database. Do we want to create that mechanism for all location revelation? 
Or just for a very limited few instances where the SIP UA cannot handle 
providing its location? I'm open to the latter here, but know it's 
uncontrollable once built.

If location was only for 911 type services, this is the best place for it.

For a location industry to have to bow the limitation of having some other 
entity always in the mix makes things inefficient at best.

At 07:35 AM 7/11/2005 +0100, Elwell, John wrote:
>James,
>
>All of what you say is reasonable in the general context of location.
>However, for emergency calls I would have thought the risk of divulging
>location information at a proxy would be better than not supplying location
>information at all (which would be the case if the UAC does not have
>appropriate support).
>
>John
>
>
> > Sent: 08 July 2005 19:40
> > Subject: RE: Comment on draft-ietf-sip-location-conveyance-00
> >
> > John
> >

cheers,
James

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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 12 Jul 2005 09:09:24 +0100

James,

See in-line.

John

> Sent: 11 July 2005 19:37
[JRE] I was not aware of that situation in the US. So maybe insertion by a
proxy can be done only in jurisdications where this is allowed without user
consent. Otherwise, if the UAC does not indicate support for receiving
location information in a 4xx response and resubmitting the request, then
the emergency call just has to proceed without location information.

> 4) or it is a URL to a reference on a server
[JRE] I have a tendency towards 4), but I don't pretend to have a grasp of
all the pros and cons yet.
> how).
[JRE] No, the UA can still provide location in a body. The URL alternative
would just be for proxy use for an emergency call where the UAC is unable to
insert location information.

> This is a means for the owner of the server the URL lives on to

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Jul 2005 12:43:03 -0500

john

in-line

At 09:09 AM 7/12/2005 +0100, Elwell, John wrote:
>[JRE] I was not aware of that situation in the US.

Most aren't - and I don't know of one that is using it. I've talked to 
folks that run PSAPs and they have to account for it, so I know it exists. 
I think I remember it originated in the state Georgia (but this is only a 
guess), and has since gone to some other states. I have not confirmed how 
wide location-anonimity this is.

>So maybe insertion by a

exactly - I have text stating the subsequent SIP Request needs to pass 
through the Proxy without a 425 Response. I can make that more 
clear/highlighted

>all the pros and cons yet.

I believe others feel the same way

>insert location information.

oh... that's different. I fully agree we should do as much as we can for 
UAs that cannot support this extension.

I'll float that variant of this scenario in the preso in Paris to see if 
the wg agrees. I have no problems with this as you stated it.

cheers,
James

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