Subject: [Sip] a question about IETF draft location conveyance 09

From: Daniel Grotti <[email-masked]>
Date: Tue, 20 Nov 2007 11:59:01 +0100

Hi all,
I'd like to ask a question about 
"draft-ietf-sip-location-conveyance-09.txt".

How does Proxy Server have to work when a Geolocation Header contain 
"recipient=endpoint" parameter ?
Does the Proxy server just have to forward the SIP message (without do 
anything else) or can it read the information conveyed ?
 
thanks,
Regards
daniel

-- 

---------------------------------------------------
Daniel Grotti
DEIS - University of Bologna
Via Venezia, 52 - 47023 Cesena (FC) - ITALY

Contacts
e-mail : [email-masked]
Skype name : Daniel Grotti
---------------------------------------------------

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Tue, 20 Nov 2007 18:33:58 -0600

Daniel

wow... you nailed this one quickly.

Neither the SIP WG nor Geopriv WG have a position with regard to 
this.  I don't like the parameter at all, and have said so from its 
introduction into discussions about putting it in the draft.  I don't 
think it accomplishes much more than confusion or a false sense of 
security by implementors.

That said, a proxy has "ar" capabilities wrt the Geolocation 
according to Table 1. (on page 7), and associated text states this 
pretty clearly. There is no text (not even a hint) that a proxy 
cannot read a location because "recipient=endpoint", therefore it 
can.  I would take this "recipient=" parameter as a hint to each type 
of SIP entity that

         + if a UAS receives this parameter (meaning in a SIP request with
            a Geolocation header), and it is set to "recipient", the UAS
            shouldn't ignore the location in the request (like it otherwise
            might).

         + If a proxy receives this parameter (meaning in a SIP request with
            a Geolocation header), and it is set to "server", the proxy
            shouldn't ignore the location in the request (like it otherwise
            might).

I don't think either indication *ever* means the other SIP entity 
type cannot view the location, based on the parameter.  The only 
exception I can think of is a Location-by-value hidden by S/MIME 
means no one save who has the decryption key can view the contents of 
what's encrypted.

Does this make sense?

James

At 04:59 AM 11/20/2007, Daniel Grotti wrote:
>Hi all,
>I'd like to ask a question about "draft-ietf-sip-location-conveyance-09.txt".
>
>Does the Proxy server just have to forward the SIP message (without 
>do anything else) or can it read the information conveyed ?
>thanks,
>Regards
>daniel
>
>--
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Nov 2007 11:51:44 -0800

At 6:33 PM -0600 11/20/07, James M. Polk wrote:
>Neither the SIP WG nor Geopriv WG have a position with regard to this.  I don't like the parameter at all, and have said so from its introduction into discussions about putting it in the draft.  I don't think it accomplishes much more than confusion or a false sense of security by implementors.

Well, I think the Geopriv working group discussed this a great deal, and that
there was reasonable (albeit rough) consensus that it be included.  Anyone
interested can certainly see a lively debate on the Geopriv list.

The current text is:
A locationValue has the following independent header parameters,

(snip of other parameters)

the "recipient=" parameter to allow recipients to infer what SIP
      element type this locationValue was intended to be for.  The
      types are

         o "endpoint" - meaning the ultimate destination UAS;

         o "routing-entity" - meaning SIP servers that route messages
                    based on the location contents of requests; and

         o "both" - meaning this locationValue is to be viewed by both
                    types of SIP entities. 

      Not all SIP entities have to read the locationValue within a
      Geolocation header, therefore a parameter value of "both" does
      not mean "every" SIP element receiving this request, it means all
      that care to pay attention to a locationValue.  The default
      behavior of SIP entities reading the locationValue is that if
      this header parameter is NOT present, the intended recipient is
      the destination UAS.

A proxy seeing a locationValue with a recipient= tag of
routing-entity or both MAY do location based routing using
the location (as the draft says, it does not have to).  A proxy
seeing a locationValue with a recipient=endpoint should understand
that the locationValue was not intended to be used for
location-based routing.    The draft is pretty clear that the
privacy rules in RFC 4119; in Section 5 it says pretty bluntly:
  
   Location Recipients MUST obey the privacy and security rules in the
   PIDF-LO as described in RFC 4119 regarding retransmission and
   retention.

If a proxy is not the intended recipient, as given in this parameter,
it shouldn't be storing or acting on this data, just sending it along.

>That said, a proxy has "ar" capabilities wrt the Geolocation according to Table 1. (on page 7), and associated text states this pretty clearly. There is no text (not even a hint) that a proxy cannot read a location because "recipient=endpoint", therefore it can.  I would take this "recipient=" parameter as a hint to each type of SIP entity that
>
>I don't think either indication *ever* means the other SIP entity type cannot view the location, based on the parameter. 

I don't understand what you mean by "view" here.  A proxy putting this to memory
in order to send it along is doing fine; someone doing location-based-routing when
recipient=endpoint is not doing the right thing (except in the Emergency Services
case, where all bets are off).

>The only exception I can think of is a Location-by-value hidden by S/MIME means no one save who has the decryption key can view the contents of what's encrypted.
>
>Does this make sense?

I suggest we continue the conversation in GeoPRIV if we have further discussion
on this particular point.
				Ted

>>How does Proxy Server have to work when a Geolocation Header contain "recipient=endpoint" parameter ?
>>Does the Proxy server just have to forward the SIP message (without do anything else) or can it read the information conveyed ?
>>thanks,
>>Regards
>>daniel
>>
>>--
>>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 14:28:27 -0600

Ted

The "recipient=" within the Geolocation header is a SIP parameter, in 
a SIP document.  Everything discussed in Geopriv regarding this 
document needs to be approved in SIP too.  The SIP WG hasn't heard 
this part of the discussion because most members of SIP aren't 
subscribed to the Geopriv list.

I'm on the agenda right now to present in SIP in Vancouver, and this 
is one issue I'd like the SIP WG to comment on, so I'll be asking it there.

the rest of my reply is in-line

At 01:51 PM 11/21/2007, Ted Hardie wrote:
> introduction into discussions about putting it in the draft.  I 
> don't think it accomplishes much more than confusion or a false 
> sense of security by implementors.
>

and where was the SIP WG discussion on a SIP header parameter?  Since 
this parameter, from what you state below,  has a UA understanding 
the topology of a request - all the way to the endpoint - which is 
not part of the Geopriv charter to know or make decisions on, where's 
that discussion, at least as confirmation that SIP UAC's can know the 
full topology of a network enough to make this decision (that can't 
be changed)?

For example, Alice calls PizzaHut.com, and Pizza Hut routes her call 
to the Pizza Hut store most local to wherever she is to take her 
order.  Does her UAC understand this type of call well enough to have 
"recipient=both"?  Or would it just enter "recipient=endpoint", thus 
preventing her SIP request from being retargetted?

How does her UAC understand the different from this type of call to 
Pizza Hut from merely a complaint to Pizza Hut corporate?

I still can't seem to get over this simple example of a limitation 
and assumption created by this header parameter that the caller 
doesn't control.

> can.  I would take this "recipient=" parameter as a hint to each 
> type of SIP entity that
> >
> type cannot view the location, based on the parameter.
>

RFC3261 says proxies can view message bodies that aren't encrypted.

I don't see the text giving an exemption in the emergency case, not 
at least in this doc.

> >The only exception I can think of is a Location-by-value hidden by 
> S/MIME means no one save who has the decryption key can view the 
> contents of what's encrypted.
> >
> >Does this make sense?
>

But this is a SIP parameter, and a SIP document.  Everything 
discussed in Geopriv needs to be approved in SIP too.  The SIP WG 
hasn't heard this part of the discussion because most members of SIP 
aren't subscribed to the Geopriv list.

> >>Does the Proxy server just have to forward the SIP message 
> (without do anything else) or can it read the information conveyed ?
> >>thanks,
> >>Regards
> >>daniel
> >>
> >>--
> >>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Nov 2007 13:02:16 -0800

At 2:28 PM -0600 11/21/07, James M. Polk wrote:
>Ted
>
>The "recipient=" within the Geolocation header is a SIP parameter, in a SIP document.  Everything discussed in Geopriv regarding this document needs to be approved in SIP too.  The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list.

That SIP parameter in a SIP document relates to a PIDF-LO object carried by
SIP; in that context, SIP is a using protocol of the GEOPRIV framework.  SIP
folks should certainly understand the work they're reusing, or the implementations
won't do the right thing.  But re-starting the conversation in SIP without
reference to the discussions that have already occurred in GeoPRIV is a
recipe for conflict at IETF Last Call.  We might as well start getting people
on the same page now.  From my  perspective, the right way to do that is
to start the discussion from where it last left off, even if that wasn't in
the same group.  That tells people where the consensus of that group was
and informs the rest of the discussion.

>
>I'm on the agenda right now to present in SIP in Vancouver, and this is one issue I'd like the SIP WG to comment on, so I'll be asking it there.

I look forward to your presentation.

Further commments inline.

>and where was the SIP WG discussion on a SIP header parameter?  Since this parameter, from what you state below,  has a UA understanding the topology of a request - all the way to the endpoint - which is not part of the Geopriv charter to know or make decisions on, where's that discussion, at least as confirmation that SIP UAC's can know the full topology of a network enough to make this decision (that can't be changed)?

You are making a big leap here.  It doesn't have a UA understanding of the topology;
it has User control over private information.  The user gets to say by whom his or
her location gets used; that's a core aspect of RFC 4119 and friends, and you don't
get to reuse that work without getting that assumption built in.  We've had
exceptions for emergency services (discussed in the ECRIT BCPs), but they're
not general.  If a user does not want that private information used by the
SIP routing system but is willing to give it to the SIP entity receiving the call,
the system has to provide a way of making that clear.  We discussed several
ways to achieve that (including changes to 4119), and there was pretty
clear consensus on this way forward.  The version with retransmission-allowed
or routing-query-allowed did not see support, nor did redefining "retransmission=no"
to mean "except for SIP".

Yes, this does mean that a UA that sends a location object with recipient=end-point
may have a call fail if location-based routing is absolutely required; so will any
call not containing location, though, and the UA will have to be able to handle
that case.  It may very well be what is wanted, as we discussed in relation to
taxi services at some length (I may be willing to send my location to a local
taxi service so it can send the taxi, but not willing to send my location to
the sip-routing system so it can pick a taxi-service local to me).

>For example, Alice calls PizzaHut.com, and Pizza Hut routes her call to the Pizza Hut store most local to wherever she is to take her order.  Does her UAC understand this type of call well enough to have "recipient=both"?  Or would it just enter "recipient=endpoint", thus preventing her SIP request from being retargetted?
>
>How does her UAC understand the different from this type of call to Pizza Hut from merely a complaint to Pizza Hut corporate?
>
>I still can't seem to get over this simple example of a limitation and assumption created by this header parameter that the caller doesn't control.

Perhaps I don't see what you mean by "caller doesn't control" here.  Can you
elaborate?

>RFC3261 says proxies can view message bodies that aren't encrypted.

And what does "view" mean here?  If it understands it enough to know
how to use a pidf-lo object for location-based routing, it pretty much has
to understand it enough to know that it is not an intended recipient of
such a body, based on the header here and the pidf-lo internal rules.
If it doesn't understand pidf-lo, then "viewing" it means something like
"copying", "forwarding", or similar, no?

>I don't see the text giving an exemption in the emergency case, not at least in this doc.

The exception is in the ECRIT documents, or was the last I checked (sorry that I
have no time to confirm now).

>But this is a SIP parameter, and a SIP document.  Everything discussed in Geopriv needs to be approved in SIP too.  The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list.

I'm reluctant to suggest cross-posting, but I do believe that folks commenting on
this should be aware of the discussion in the Geopriv group prior to this.  I continue
to recommend that folks review the geopriv archive, searching for the document
name, in order to get that context.

Note that deciding to ignore the privacy implications of geopriv's framework is
simply going to create "confusion and delay", as my son's favorite railroad
director says, and if we actually hope to see this work we need to work within
the framework as much as we can.

			regards,
				Ted Hardie

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 16:18:30 -0600

At 03:02 PM 11/21/2007, Ted Hardie wrote:
> >The "recipient=" within the Geolocation header is a SIP parameter, 
> in a SIP document.  Everything discussed in Geopriv regarding this 

Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains 
to the SIP WG's expertise in knowing and agreeing with SIP's ability 
to foresee the type of topology from UAC to UAS, and each server 
(whether there even is one) in between.  I'm not so sure the SIP WG 
agrees that a UAC can make this determination, and am soliciting 
their input here in a broad way.

Can a UAC understand enough about the topology of the Internet to 
understand where it is sending a request, including how SIP servers 
may or may not act upon that request?

I believe, if the answer is no, the the "recipient=" parameter is a 
flawed SIP header parameter.

If the answer is yes, then it stays with no further arguments from me.

> >
> >I'm on the agenda right now to present in SIP in Vancouver, and 
> this is one issue I'd like the SIP WG to comment on, so I'll be 
> asking it there.
>

The above question is what I'll propose to the SIP WG, nothing 
more.  If they ask for an example, I'll give them the Pizza Hut 
example I did on this thread a few messages ago.

> >and where was the SIP WG discussion on a SIP header 
> parameter?  Since this parameter, from what you state below,  has a 
> UA understanding the topology of a request - all the way to the 
> endpoint - which is not part of the Geopriv charter to know or make 
> decisions on, where's that discussion, at least as confirmation 
> that SIP UAC's can know the full topology of a network enough to 
> make this decision (that can't be changed)?
>
> >For example, Alice calls PizzaHut.com, and Pizza Hut routes her 
> call to the Pizza Hut store most local to wherever she is to take 
> her order.  Does her UAC understand this type of call well enough 
> to have "recipient=both"?  Or would it just enter 
> "recipient=endpoint", thus preventing her SIP request from being retargetted?
> >
> >How does her UAC understand the different from this type of call 
> to Pizza Hut from merely a complaint to Pizza Hut corporate?
> >
> >>>I don't think either indication *ever* means the other SIP 
> entity type cannot view the location, based on the parameter.
> >>
> >> >The only exception I can think of is a Location-by-value hidden 
> by S/MIME means no one save who has the decryption key can view the 
> hasn't heard this part of the discussion because most members of 
> SIP aren't subscribed to the Geopriv list.
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Nov 2007 15:36:18 -0800

At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>\
>Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains to the SIP WG's expertise in knowing and agreeing with SIP's ability to foresee the type of topology from UAC to UAS, and each server (whether there even is one) in between.  I'm not so sure the SIP WG agrees that a UAC can make this determination, and am soliciting their input here in a broad way.
>
>Can a UAC understand enough about the topology of the Internet to understand where it is sending a request, including how SIP servers may or may not act upon that request?
>
>I believe, if the answer is no, the the "recipient=" parameter is a flawed SIP header parameter.
>

I think we have fundamentally different ideas of how much understanding of the
topology this implies.  My view is that the header as currently specified says
either "This is meant for the person answering the call/taking the session" or
"This is meant to help get the call through/get the session to the right responder".
Within the latter case, it requires no knowledge at all of topology; it does
not distinguish among the many different routing elements which might be
trying to make that happen. 

A UA that does not care whether it is used for routing can enter "both"
and all is well.  A UA that *wants* it to be used this way can enter "routing-entity".
The availability of "endpoint" as a separate possibility makes sure that
an endpoint can indicate that use by the routing system is not intended. 
If the SIP community believes "routing-entity" is too vague
and needs to be broken out, I do not see how the GeoPRIV could object or
why it would want to; certainly this working group should have the final word
on that.  But collapsing things so that entering "endpoint" is
not an indicator to the routing entities that they should just pass things along
would find opposition (at the very least from me).  That would break a pretty
fundamental assumption that users are in control of the pidf-lo distributions.

Hope you have a great Thanksgiving,
				Ted

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Nov 2007 19:10:09 -0600

> and informs the rest of the discussion.

Supposedly, the discussion in GEOPRIV was a joint SIP/GEOPRIV effort.

A brief recap of the conclusion in GEOPRIV might be reasonable, but  
I'd much rather not revisit the thousands of emails on the topic in  
GEOPRIV. If we notice now that it is broken in some horrible way we  
didn't, before, that might change the situation, but we shouldn't  
rehash the entire design rationale.

--
Dean

---

From: "daniel grotti" <[email-masked]>
Date: Thu, 22 Nov 2007 17:56:52 +0100

I believe that if a UA puts "recipient=routing-entity" paramenter into locationValue, the location information should be read only by Proxy Server for location-based routing. 
But if a UA wants its own location information to be known and seen by endusers, then UA have to insert the "recipient=endpoints" paramenter. In this case Proxy server, from my view, should only forward the message to the destination. UA would just like to bring its own location to an endpoint, and    could not interested in location-based routing.

Does this make sense?

Regards,
Daniel

-----------------------------
       Daniel  Grotti
DEIS - Universita' di Bologna
-----------------------------
       Via Venezia, 52
  47023 Cesena (FC) - ITALY
-----------------------------
email:[email-masked]
-----------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Nov 2007 18:35:03 +0100

Hi Daniel,

> But if a UA wants its own location information to be known and seen by endusers, then UA have to insert the "recipient=endpoints" paramenter. In this case Proxy server, from my view, should only fo…

Correct and makes sense.

The recipient parameter is just a hint for processing. It does not have 
security properties.

Ciao
Hannes

---

From: "daniel grotti" <[email-masked]>
Date: Thu, 22 Nov 2007 19:08:23 +0100

Hi all,
so why don't emphasize this point in the next draft, saying : "Proxy server MUST not read messages with "recipient=endpoint" paramenter setted".
This is my point of you.

What do you think? James?

Regards,
Daniel

----------------------------------
       Daniel  Grotti
D.E.I.S. - University of Bologna
----------------------------------
       Via Venezia, 52
  47023 Cesena (FC) - ITALY
----------------------------------
e-mail: [email-masked]
---------------------------------- 

-----Messaggio originale-----
Da: Hannes Tschofenig [mailto:[email-masked]]
Inviato: gio 22/11/2007 18.35
A: daniel grotti
Cc: Ted Hardie; James M. Polk; IETF SIP List
Oggetto: Re: R: [Sip] a question about IETF draft location conveyance 09
 
Hi Daniel,

Correct and makes sense.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Nov 2007 20:27:53 +0100

RFC 2119 language aims to accomplish interoperability.
The MUST NOT in that sentence does not accomplish interoperability.
It does not do harm for the proxy to still read it.

I would be fine with a sentence that indicates that it is not useful for 
the proxy to read the location information if the recipient parameter is 
set to "endpoint".

Ciao
Hannes

---

From: "daniel grotti" <[email-masked]>
Date: Thu, 22 Nov 2007 20:46:13 +0100

yes, right. :)

Ciao
daniel

-----Messaggio originale-----
Da: Hannes Tschofenig [mailto:[email-masked]]
Inviato: gio 22/11/2007 20.27
A: daniel grotti
Cc: Ted Hardie; James M. Polk; IETF SIP List
Oggetto: Re: R: R: [Sip] a question about IETF draft location conveyance 09

Ciao
Hannes

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Nov 2007 19:32:41 -0600

On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:

> Hi all,
> so why don't emphasize this point in the next draft, saying :  
> "Proxy server MUST not read messages with "recipient=endpoint"  
> paramenter setted".
> This is my point of you.
>
>

because from a security standpoint, this prohibition is meaningless.  
Intermediate nodes can and will read anything that's in plaintext,  
and SOMEBODY will come up with a rationale, in some context or  
another, for doing so.

And has been pointed out, doing so does not appear to create a  
compatibility problem. It doesn't break the protocol. It might defeat  
security-through-obscurity. It might be rude, or otherwise socially  
unacceptable. But those don't qualify for a MUST level protocol  
prohibition.

--
Dean

---

From: "daniel grotti" <[email-masked]>
Date: Sat, 24 Nov 2007 12:37:55 +0100

I know. 
May be SHOULD NOT instead MUST NOT could be better.

daniel

-----Messaggio originale-----
Da: Dean Willis [mailto:[email-masked]]
Inviato: sab 24/11/2007 2.32
A: daniel grotti
Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
Oggetto: Re: R: R: [Sip] a question about IETF draft location conveyance 09

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 26 Nov 2007 15:28:10 +0100

This just seems to me to be an inappropriate change of RFC 2119 language. 

If we really mean either of these, then we should be specifying that the message is encrypted in the first place.

What we probably mean is something informative (because we cannot make a normative statement on what applications do with the data), stating that usage of the message so tagged is inappropriate because the sender did not intend it to be used for this purpose.

Regards

Keith

> -----Original Message-----
> From: daniel grotti [mailto:[email-masked]] 
> Sent: Saturday, November 24, 2007 11:38 AM
> To: Dean Willis
> Cc: IETF SIP List; James M. Polk
> Subject: R: R: R: [Sip] a question about IETF draft location 
> conveyance 09
> 
> I know. 
> Intermediate nodes can and will read anything that's in 
> plaintext, and SOMEBODY will come up with a rationale, in 
> some context or another, for doing so.
> 
> And has been pointed out, doing so does not appear to create 
> a compatibility problem. It doesn't break the protocol. It 
> might defeat security-through-obscurity. It might be rude, or 
> otherwise socially unacceptable. But those don't qualify for 
> a MUST level protocol prohibition.
> 
> --
> Dean
> 
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Nov 2007 15:02:35 -0600

This also gets back to one of my original points, does SIP expect a 
UAC to understand the topology of a message's path to the ultimate destination?

Is Ted's intent of the "recipient=endpoint" parameter to prevent 
proxies from reading location in a message *and* a "recipient=server" 
parameter to prevent endpoints from reading location in a message?

Does the UAC always know that there are only proxies between it and 
the destination UAS?

Does the UAC always understand a particular message does or does not 
need to be routed based on the location within the request?

Emergency services is an example of, always allow proxy routing when 
the UAC knows this is an emergency request.  But will this be true 
for all applications of location conveyance in the (relatively 
near-term) future?  I'm not so sure.

The UAC has a mechanism for making location not readable by proxies 
if it doesn't want them to, use encryption e2e.  But this has 
interesting properties in at least one case, the a user calls the 
nearest Pizza Hut.

A UAC can encrypt its location in the first INVITE, but if Pizza Hut 
has a national or regional number, that routes on the location of the 
caller, the message will probably return a 493 (undecipherable).

Does the UAC then send location to PizzaHut.com unencrypted, knowing 
this is required to get the INVITE to the right store?

There are other usages of this, other than Pizza Hut.

Does anyone have a suggestion for informative text that can address 
each of these two (or more) situations?

At the moment, all text around "recipient=" is suggestive, and not 
definitive, because of what Dean says below.

That said, I could put something in like "unless a future standards 
track RFC says otherwise, the use of "recipient=" parameter within 
any locationValue is informative in nature", thus leaving the door 
open for ECRIT's phoneBCP doc to refine usage in the emergency 
context, as well as any other service defining document to do the 
same type of refinement.

James

At 08:28 AM 11/26/2007, DRAGE, Keith \(Keith\) wrote:
>If we really mean either of these, then we should be specifying that 
>the message is encrypted in the first place.
>
>What we probably mean is something informative (because we cannot 
>make a normative statement on what applications do with the data), 
>stating that usage of the message so tagged is inappropriate because 
>the sender did not intend it to be used for this purpose.
>
>Regards
>
>Keith
>

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 26 Nov 2007 17:06:28 -0500

James,

I do believe that the intent of Ted (as well as others in the GEOPRIV 
working group, including myself) is that if a UAC specifies 
"recipient=endpoint" then a compliant proxy will not 'read' the location 
body. In particular, "recipient=endpoint" indicates that a SIP proxy in 
the signaling path does not have permission to store the location (or 
any derived information) for longer than is necessary to forward the SIP 
message and does not have permission to send the location to any third 
party (for any reason including location-based routing) other than the 
next-hop SIP proxy. That is, the intent of "recipient=endpoint" that if 
a call requires location-based routing in order to succeed, then the 
call should fail.

Personally, I believe (and I think this is a point Ted was trying to 
make) that a UAC must have a way to indicate that a location is to be 
read by the endpoint and no one else. This goes back to RFC 3693 which 
dictates that a target must have a way of articulating privacy rules and 
that using protocols must enforce those rules. In particular, see 
requirements 7, 10 and 11 in RFC 3693. (Note that RFC 3693 explicitly 
makes an exception for the emergency case, and so this discussion is in 
the context of non-emergency conveyance of location information ... e.g. 
Pizza Hut.)

(Also note: there is always the issue that a malicious proxy might not 
obey the wishes expressed by the UAC, but SIP is an architecture in 
which there is implicit trust by the UAC that the proxy acting on his 
behave properly and comply with all relevant specifications. 
Implications of the SIP trust model are a topic for another thread ... 
See for example:  
http://www1.ietf.org/mail-archive/web/sip/current/msg20319.html)

Clearly, there are many mechanisms that satisfy the desideratum that a 
target be able to indicate that its location is to be read only by the 
SIP endpoint. For example, this desire could be encoded as a privacy 
rule within the PIDF-LO and each SIP proxy could parse the privacy rules 
in a PIDF-LO to determine the target's intent. Alternatively, a 
location-by-value could be encrypted end-to-end; or location could be 
conveyed by-reference using an LIS with certificate-based access 
controls. The GEOPRIV working group discussed various mechanisms last 
May (See the thread beginning with: 
http://www1.ietf.org/mail-archive/web/geopriv/current/msg03521.html) and 
I believe there was rough consensus that the "recipient=endpoint" 
mechanism described in the current conveyance draft was the best 
mechanism for achieving the above desideratum.

This seems to leave us with three options going forward:

1) Deny the UAC the opertunity to indicate that location is to be read 
only by the SIP endpoint. (That is, declare that SIP is not a GEOPRIV 
using protocol in sense of RFC 3693).

2) Revisit the mechanism discussion and attempt to reach consensus on a 
better mechanism for indicating that location is to be read only by the 
SIP endpoint.

3) Craft text explaining that when the "recipient=endpoint" parameter is 
used that a compliant SIP proxy is not to 'read' the location 
information. (Note that this text should also indicate that when 
"recipient=endpoint" is used that calls requiring location-based routing 
will fail, and thus should only be used when call failure is preferred 
over disclosure of location information to a routing entity.)

- Matt Lepinski

James M. Polk wrote:

> the UAC knows this is an emergency request.  But will this be true for 
> all applications of location conveyance in the (relatively near-term) 
> future?  I'm not so sure.
>
> The UAC has a mechanism for making location not readable by proxies if 
> it doesn't want them to, use encryption e2e.  But this has interesting 
> properties in at least one case, the a user calls the nearest Pizza Hut.
>
> track RFC says otherwise, the use of "recipient=" parameter within any 
> locationValue is informative in nature", thus leaving the door open 
> for ECRIT's phoneBCP doc to refine usage in the emergency context, as 
> well as any other service defining document to do the same type of 
> refinement.
>
> James
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Nov 2007 18:21:47 -0600

Matt

in-line

At 04:06 PM 11/26/2007, Matt Lepinski wrote:
>James,
>
>I do believe that the intent of Ted (as well as others in the 
>GEOPRIV working group, including myself) is that if a UAC specifies 
>"recipient=endpoint" then a compliant proxy will not 'read' the location body.

Why isn't the message body not encrypted to make sure the Proxy doesn't?

What about the situation in which there are multiple proxies between 
Alice and Bob, but only one will do anything good with the 
location.  What is "recipient=" set to, to ensure only the good proxy 
reads the location body, and the no-so-good proxies obey the 
parameter and don't look at the location?

>In particular, "recipient=endpoint" indicates that a SIP proxy in 
>the signaling path does not have permission to store the location 
>(or any derived information) for longer than is necessary to forward 
>the SIP message and does not have permission to send the location to 
>any third party (for any reason including location-based routing) 
>other than the next-hop SIP proxy.

The RFC4119 defined PIDF-LO <retransmission-allowed> element (section 
2.2.2) covers this already, for any proxy that reads the message 
body. Why does this also need to be in a SIP header parameter?

What you describe above is a proxy that receives a SIP request, uses 
location (without sending it to anywhere else) to determine its next 
SIP hop, and forwards the message. Yet, this isn't the scenario you 
want, is it?

>That is, the intent of "recipient=endpoint" that if a call requires 
>location-based routing in order to succeed, then the call should fail.

With what error?

-09 defines lots of errors, but not one for this type of error - in 
which the UAC knows how to correct it in a subsequent message it 
doesn't want to fail for the same reason.

What is the SIP response, for that matter? It is not a timeout 
message, and it is not a server refusal message.  Is it simply a 400?

That said, if there is not a Geolocation-Error code, the UAC is blind 
as to what to do.

>make) that a UAC must have a way to indicate that a location is to 
>be read by the endpoint and no one else.

See, I think this is covered by SIP with the use of message body 
encryption, or in 4119 with a <retransmission-allowed> element set to "no".

>This goes back to RFC 3693 which dictates that a target must have a 
>way of articulating privacy rules and that using protocols must 
>enforce those rules.

-09 states the usage-rules of 3693 are to be maintained, and the 
<retransmission-allowed> element set to "no" addresses this, IMO.

>In particular, see requirements 7, 10 and 11 in RFC 3693. (Note that 
>RFC 3693 explicitly makes an exception for the emergency case, and 
>so this discussion is in the context of non-emergency conveyance of 
>location information ... e.g. Pizza Hut.)

fair, but know that I'm a co-author of 3693, and I'm the one who put 
in the exception for the emergency case text in that RFC.

>(Also note: there is always the issue that a malicious proxy might 
>not obey the wishes expressed by the UAC, but SIP is an architecture 
>in which there is implicit trust by the UAC that the proxy acting on 
>his behave properly and comply with all relevant specifications. 
>Implications of the SIP trust model are a topic for another thread 
>... See for example:
>Clearly, there are many mechanisms that satisfy the desideratum that 
>a target be able to indicate that its location is to be read only by 
>the SIP endpoint.

yeah, encryption ensure this, a header parameter doesn't.

>For example, this desire could be encoded as a privacy rule within 
>the PIDF-LO and each SIP proxy could parse the privacy rules in a 
>PIDF-LO to determine the target's intent.

that has been discussed previously, and is the URI that is in the 
optional "ruleset-reference" element, that's within section 2.2.2 of RFC 4119.

>Alternatively, a location-by-value could be encrypted end-to-end; or 
>location could be conveyed by-reference using an LIS with 
>certificate-based access controls. The GEOPRIV working group 
>discussed various mechanisms last May (See the thread beginning 
>with: 
>http://www1.ietf.org/mail-archive/web/geopriv/current/msg03521.html) 
>and I believe there was rough consensus that the 
>"recipient=endpoint" mechanism described in the current conveyance 
>draft was the best mechanism for achieving the above desideratum.

This is something that the SIP WG needed to be in on, since this is 
not a Geopriv header parameter, it is a SIP header parameter.  Given 
that one SIP WG chair has already said this mechanism is doubtful to 
work, there needs to be a more thorough discussion in SIP about this.

>This seems to leave us with three options going forward:

Exactly who is "us" in the above?

>1) Deny the UAC the opertunity to indicate that location is to be 
>read only by the SIP endpoint. (That is, declare that SIP is not a 
>GEOPRIV using protocol in sense of RFC 3693).

encryption of the message body does this, all of which is already 
defined in SIP (RFC 3261), so this option is not really a choice

>2) Revisit the mechanism discussion and attempt to reach consensus 
>on a better mechanism for indicating that location is to be read 
>only by the SIP endpoint.

How doesn't encryption do this?

BTW - the discussion needs to be in the Using Protocol's WG, where 
the expertise is for that Using protocol.

>3) Craft text explaining that when the "recipient=endpoint" 
>parameter is used that a compliant SIP proxy is not to 'read' the 
>location information. (Note that this text should also indicate that 
>when "recipient=endpoint" is used that calls requiring 
>location-based routing will fail, and thus should only be used when 
>call failure is preferred over disclosure of location information to 
>a routing entity.)

This option is only satisfied when there is an agreeable SIP response 
with Geolocation-Error code indication that informs the UAC why this 
failure occurred, so it can make an informed decision about what the 
next step is.

>>proxies from reading location in a message *and* a 
>>"recipient=server" parameter to prevent endpoints from reading 
>>location in a message?
>>
>>Does the UAC always understand a particular message does or does 
>>not need to be routed based on the location within the request?
>>
>>Emergency services is an example of, always allow proxy routing 
>>when the UAC knows this is an emergency request.  But will this be 
>>true for all applications of location conveyance in the (relatively 
>>A UAC can encrypt its location in the first INVITE, but if Pizza 
>>Hut has a national or regional number, that routes on the location 
>>of the caller, the message will probably return a 493 (undecipherable).
>>
>>Does the UAC then send location to PizzaHut.com unencrypted, 
>>knowing this is required to get the INVITE to the right store?
>>
>>>If we really mean either of these, then we should be specifying 
>>>that the message is encrypted in the first place.
>>>
>>>stating that usage of the message so tagged is inappropriate 
>>>because the sender did not intend it to be used for this purpose.
>>>
>>>Regards
>>>
>>>Keith
>>>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Nov 2007 16:35:46 -0800

At 3:02 PM -0600 11/26/07, James M. Polk wrote:
>This also gets back to one of my original points, does SIP expect a UAC to understand the topology of a message's path to the ultimate destination?

I don't think it ever did.  Why would it do so now?

>Is Ted's intent of the "recipient=endpoint" parameter to prevent proxies from reading location in a message *and* a "recipient=server" parameter to prevent endpoints from reading location in a message?

PIDF-LO resources contain statements about things like retransmission.  The intent here
is to make sure those reading the SIP message containing a PIDF-LO understand to
whom those statements are being made.  If you are not the intended recipient,
you do not act on the basis of the information in the PIDF-LO; you either forward it
along (routing-entity) or ignore it (endpoint).

Yes, this expects folks to behave according to the rules in a pidf-lo without
encryption forcing them to, or a gun to their head, or any other coercion.  That's
been the case for pidf-lo resources for a long time now, and it should not come
as a suprise to at least those that have followed that discussion.  If you would
like to re-visit it, expect to be working on this document for a long, long time.

>Does the UAC always know that there are only proxies between it and the destination UAS?
>
>Does the UAC always understand a particular message does or does not need to be routed based on the location within the request?

Try asking the question "Are there circumstances in which the US can decide not to
allow its location to be used in determining where to route the call?"   We had that
discussion over many months, and, I think the rough consensus was yes.  The result
of that may well be calls that do not go through--but that is the consequence of
the UA-determined behavior.  It's their location, and they control it in the
PIDF-LO world.

>Emergency services is an example of, always allow proxy routing when the UAC knows this is an emergency request.  But will this be true for all applications of location conveyance in the (relatively near-term) future?  I'm not so sure.
>
>The UAC has a mechanism for making location not readable by proxies if it doesn't want them to, use encryption e2e.  But this has interesting properties in at least one case, the a user calls the nearest Pizza Hut.

There's a difference between "not readable" and "does not desire that the proxy act on
it".    You don't need all the heavyweight mechanisms of encryption to say to the
routing system "the included location is not intended for you; don't do location based
routing using it--fail instead".  All you need for that is knowledge of the intended
recipient.  Encryption is available for cases where the end-user feels it is needed,
but it should not be required for the base case.

>A UAC can encrypt its location in the first INVITE, but if Pizza Hut has a national or regional number, that routes on the location of the caller, the message will probably return a 493 (undecipherable).
>
>Does the UAC then send location to PizzaHut.com unencrypted, knowing this is required to get the INVITE to the right store?
>
>Does anyone have a suggestion for informative text that can address each of these two (or more) situations?
>
>At the moment, all text around "recipient=" is suggestive, and not definitive, because of what Dean says below.
>
>That said, I could put something in like "unless a future standards track RFC says otherwise, the use of "recipient=" parameter within any locationValue is informative in nature", thus leaving the door open for ECRIT's phoneBCP doc to refine usage in the emergency context, as well as any other service defining document to do the same type of refinement.

If you do that, you are violating both the rough consensus of the GeoPRIV working group,
and the use of PIDF-LO as already set out in standards track documents.  Don't expect
smooth sailing on that.

Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Nov 2007 17:11:42 -0800

At 6:21 PM -0600 11/26/07, James M. Polk wrote:
>>I do believe that the intent of Ted (as well as others in the GEOPRIV working group, including myself) is that if a UAC specifies "recipient=endpoint" then a compliant proxy will not 'read' the location body.
>
>What about the situation in which there are multiple proxies between Alice and Bob, but only one will do anything good with the location.  What is "recipient=" set to, to ensure only the good proxy reads the location body, and the no-so-good proxies obey the parameter and don't look at the location?

To go back to your first question, how does proxy 1 know that later proxies
won't do anything with the location if they are permitted to?  Having
a UA able to say "permit this for routing-entities/don't permit this for routing-entities"
is pretty binary, but discussion in the past covered the problems with trying
to enumerate roles beyond that. 

>>In particular, "recipient=endpoint" indicates that a SIP proxy in the signaling path does not have permission to store the location (or any derived information) for longer than is necessary to forward the SIP message and does not have permission to send the location to any third party (for any reason including location-based routing) other than the next-hop SIP proxy.
>
>The RFC4119 defined PIDF-LO <retransmission-allowed> element (section 2.2.2) covers this already, for any proxy that reads the message body. Why does this also need to be in a SIP header parameter?

James, we had this discussion over many months in the geopriv working group.  You
were certainly present for all of that; if you want to summarize the arguments made
and detail where you disagree, that would be useful.  Acting as if the questions
hadn't been asked and answered already is both tedious and tendentious.  It's deeply
weird to talk to the author of a document that includes all these changes based on
those agreements while the author is acting like those changes appeared magically
by the action of bad elves. 

As the previous discussion made clear, relying on "retransmission-allowed" without a clear statement of the intended recipient would bounce a lot of messages, as the default is "no".  The suggestion that "no" be considered yes for routing was a non-starter.
Recommending that retransmission-allowed be set to "yes" for all the cases of
location-based routing would mean both that the  intermediate systems could use it
*and that the end-user would be able to retransmit it*, which might not be wanted. 
Your previous draft suggested an update to RFC 4119 to include a
"routing-query-allowed" element; geopriv didn't want to make a generic change
to 4119 for what seemed like a SIP-specific case when a SIP header mechanism
looked like it worked as well or better.  (For what it's worth, I agreed with that,
but was also personally willing to tolerate the cruft to get the right thing done)

Are we back on the same page here?

>
>fair, but know that I'm a co-author of 3693, and I'm the one who put in the exception for the emergency case text in that RFC.

And we all have agreed, many times, that all bets are off in the emergency case;
if an emergency system needs to route based on an included location, it gets to
ignore this value.  That doesn't change the base design.

>
>>Alternatively, a location-by-value could be encrypted end-to-end; or location could be conveyed by-reference using an LIS with certificate-based access controls. The GEOPRIV working group discussed various mechanisms last May (See the thread beginning with: http://www1.ietf.org/mail-archive/web/geopriv/current/msg03521.html) and I believe there was rough consensus that the "recipient=endpoint" mechanism described in the current conveyance draft was the best mechanism for achieving the above desideratum.
>
>This is something that the SIP WG needed to be in on, since this is not a Geopriv header parameter, it is a SIP header parameter.  Given that one SIP WG chair has already said this mechanism is doubtful to work, there needs to be a more thorough discussion in SIP about this.

As I asked before, and Dean reinforced, please start from the GeoPRIV consensus.
If you don't do that, we're going to have a long, hard slog through something that
is otherwise pretty damn close to done.

>Exactly who is "us" in the above?

James, come on.  How about "those of us who care"?

>
>>1) Deny the UAC the opertunity to indicate that location is to be read only by the SIP endpoint. (That is, declare that SIP is not a GEOPRIV using protocol in sense of RFC 3693).
>
>encryption of the message body does this, all of which is already defined in SIP (RFC 3261), so this option is not really a choice

But without this, you're still left with the same problem.  If there is a plain text
pidf-lo and "retransmission=no" (remember, kids, that's the default), what does
the routing entity do after doing location-based routing?

>
>>2) Revisit the mechanism discussion and attempt to reach consensus on a better mechanism for indicating that location is to be read only by the SIP endpoint.
>

Because e2e encryption isn't available in at least some of the cases we've
discussed?

>BTW - the discussion needs to be in the Using Protocol's WG, where the expertise is for that Using protocol.

But it has to be based on the principles already set out in the documents that
Using Protocol has chosen to reference.  You want to re-use GeoPRIV for
something, you don't get to ignore those principles.  We've been through
that several times already, eh?

>
>>3) Craft text explaining that when the "recipient=endpoint" parameter is used that a compliant SIP proxy is not to 'read' the location information. (Note that this text should also indicate that when "recipient=endpoint" is used that calls requiring location-based routing will fail, and thus should only be used when call failure is preferred over disclosure of location information to a routing entity.)
>
>This option is only satisfied when there is an agreeable SIP response with Geolocation-Error code indication that informs the UAC why this failure occurred, so it can make an informed decision about what the next step is.

			regards,
				Ted

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Nov 2007 23:57:03 -0600

> a call requires location-based routing in order to succeed, then the

RFC 2119 defines MUST NOT. It says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification

I can't see any failure of interoperability that results if a proxy
"reads" the location body in violation of the user's preference
described by "recipient=endpoint". I can also see application scenarios
(ex: emergency) where applications can be assured of not operating
unless the proxy violates this prohibition. So we've missed the #6
guidance on "MUST NOT".

Can we justify a "MUST NOT" based on security considerations? Given (as
in emergency) that there are applications in which the application MUST
read the location, I don't think so.

What we really have is guidance that says, in normal operation, proxies
don't include the location in application logic when recipient=endpoint
is specified by the user, because in general this indicator means that
the user is asking the proy to NOT include the location in application
logic by attaching this modifier.

So we're at the level of a "SHOULD NOT", not a "MUST NOT" as described
by RFC 2119. And even then I suspect the discussion of this requirement
needs careful elucidation as to the problems resulting (or likely to
result) if a proxy violates this requirement.

--
Dean