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

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Jul 2005 07:35:38 +0100

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

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: 08 July 2005 19:40
> To: Elwell, John
> Cc: [email-masked]
> Subject: RE: Comment on draft-ietf-sip-location-conveyance-00
> 
> John
> 
> At 09:44 AM 7/8/2005 +0100, Elwell, John wrote:
> >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.
> 
> 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?
> 
> 
> >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
> > >
> > > 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.
> > >
> 
> 
> 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: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2005 10:31:08 -0400

I think we have two orthogonal dimensions:

- conferring location by value or by reference;

- carrying location in the header or in a body part.

All four combinations are possible. In particular, there is no 
restriction on the length of headers in SIP and the likely length of a 
location header is no larger than, say, a bunch of Via headers. Like any 
  XML object, it can be secured (authenticated, encrypted) using XMLDSIG.

There are general trade-offs between 'by value' and 'by reference'. 'By 
value' ensures atomicity - wherever the request goes, the by-value 
information goes as well. This happens to be important for emergency 
calling since emergency calls are often forwarded and redirected to a 
variety of parties with need-to-know, including backup PSAPs and first 
responders.

On the other hand, by-reference allows to differentiate access to call 
information from access to location information. (However, XMLDSIG also 
allows this to some extent, in a PK context.)

By-reference is also likely to be smaller in the SIP request, but the 
overall system byte efficiency may well be less - after all, the 
entities needing the location information will likely have to set up a 
connection (TCP, TLS, whatever) to the location server, with the time 
and space overhead of that setup swamping the object size itself.

By reference also means that there's a violation of fate sharing - a 
call may fail due to the inability of a proxy to dereference the 
location pointer, e.g., due to network failures, server overload, NAT 
issues, race conditions or authentication failures.

Thus, I think it would be helpful to look at this more systematically 
and from a whole-systems perspective.

Henning

---

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

Henning

This is a good argument for analysis (I do not disagree with anything you 
wrote below), but this doesn't exactly help me in the short term in which I 
have to update the Location ID (by next Monday morning).

Do I create the Location by reference header (with supporting requirements 
and scemantic text for it)?

Or

Do we continue this analysis before I modify the ID?

I believe that once it's in the ID, it'll be hard to take out.

comments please

At 10:31 AM 7/11/2005 -0400, Henning Schulzrinne wrote:
>All four combinations are possible. In particular, there is no restriction 
>on the length of headers in SIP and the likely length of a location header 
>is no larger than, say, a bunch of Via headers. Like any  XML object, it 
>can be secured (authenticated, encrypted) using XMLDSIG.
>
>overall system byte efficiency may well be less - after all, the entities 
>needing the location information will likely have to set up a connection 
>(TCP, TLS, whatever) to the location server, with the time and space 
>overhead of that setup swamping the object size itself.
>
>By reference also means that there's a violation of fate sharing - a call 
>may fail due to the inability of a proxy to dereference the location 
>pointer, e.g., due to network failures, server overload, NAT issues, race 
>conditions or authentication failures.
>
>Thus, I think it would be helpful to look at this more systematically and 
>from a whole-systems perspective.
>
>Henning
>
>Elwell, John wrote:
>>James,

cheers,
James

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2005 15:05:21 -0400

There seems to be sufficient confusion about the various options and 
their properties that clearly documenting their engineering trade-offs 
might speed convergence on a solution. Once we agree on the properties, 
we might be better able to decide which ones are important and whether 
these are complementary solutions that offer different trade-offs and 
should be pursued.

Since the abstract calls the document "framework and requirements", it 
seems helpful to capture some of the trade-offs, particularly since the 
discussion takes place in two, if not three, working groups, leading to 
a fair amount of re-hash or partial discussions.

I'm happy to send text.

Henning

James M. Polk wrote:
> Henning
> 
> This is a good argument for analysis (I do not disagree with anything 
> you wrote below), but this doesn't exactly help me in the short term in 
> which I have to update the Location ID (by next Monday morning).
> 
> Do I create the Location by reference header (with supporting 
> requirements and scemantic text for it)?
> 
> Or
> 
>> location header is no larger than, say, a bunch of Via headers. Like 
>> any  XML object, it can be secured (authenticated, encrypted) using 
>> XMLDSIG.
>>
>> There are general trade-offs between 'by value' and 'by reference'. 
>> 'By value' ensures atomicity - wherever the request goes, the by-value 
>> information from access to location information. (However, XMLDSIG 
>> also allows this to some extent, in a PK context.)
>>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 11 Jul 2005 14:17:28 -0500

I'd be a fool to not accept a text offering.

I think it best to create a separate subsection dealing with this topic in 
the framework&Requirements section rather than integrating anything 
throughout the doc, as the rest of the doc - 60% of it - is a solution set 
per SIP Method, per conveyance type (e2e or Proxy-Routing)

This new subsection gives a point of discussion I can bring out in the WG 
presentation on this ID too.

At 03:05 PM 7/11/2005 -0400, Henning Schulzrinne wrote:
>There seems to be sufficient confusion about the various options and their 
>properties that clearly documenting their engineering trade-offs might 
>speed convergence on a solution. Once we agree on the properties, we might 
>be better able to decide which ones are important and whether these are 
>complementary solutions that offer different trade-offs and should be pursued.
>
>discussion takes place in two, if not three, working groups, leading to a 
>fair amount of re-hash or partial discussions.
>
>I'm happy to send text.
>
>Henning
>
>James M. Polk wrote:
>>Henning
>>wrote below), but this doesn't exactly help me in the short term in which 
>>I have to update the Location ID (by next Monday morning).
>>>any  XML object, it can be secured (authenticated, encrypted) using XMLDSIG.
>>>

cheers,
James

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