Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer

From: "James M. Polk" <[email-masked]>
Date: Sat, 03 Jun 2006 17:32:23 -0500

[took Geopriv alias off]

Question - shouldn't we assume in this example that [email-masked] 
is a B2BUA, making it a destination - allowing it to open and read the 
S/MIME body?

I'm asking this because this seems like it could be a logical operation of 
Pizza-Hut's SIP infrastructure under the conditions you've laid out.

At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote:
>I don't see this as a problem.
>
>Let's take the non-emergency case.
>
>If I call [email-masked], and I want location based routing, I put
>my location header in the call, and send the call with TLS.  My outbound
>proxy will properly ignore it.  The pizza-hut domain is the one that wants
>to do location based routing, it will get the location and send it off.  I
>don't need to tell it to do that.  I could imagine a generic location based
>routing proxy, but I would not think we would want to mark the location
>header as the way to get it invoked; we need something else (directly, or
>indirectly, a Route header) to do that.
>
>If I want the endpoint to get it, then I protect it with S/MIME and no proxy
>sees it.
>
>Brian
>
>-----Original Message-----
>From: Tschofenig, Hannes [mailto:[email-masked]]
>Sent: Monday, May 22, 2006 10:54 AM
>To: Brian Rosen; Hannes Tschofenig; [email-masked]; [email-masked]
>Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer
>
>Hi Brian,
>
> > I would say no.  If the location is not needed by proxies,
> > then I would say
> > you MUST protect it (S/MIME), or it will not be private.
>I am less concerned about the security aspects here and more focused the
>protocol operation first.
>Typically, it is good to know for a device whether it has to process the
>content of the message or not.
>
>If you want to prevent intermediaries to inspect your location object
>then S/MIME might be a choice (at least on paper).
>
> >
> > If you have to route on it (emergency or otherwise), then you
> > have to send
> > it with TLS, and the proxies can see it.
> >
> > Brian
>
>Ciao
>Hannes
>
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:[email-masked]]
> > Sent: Sunday, May 21, 2006 7:40 AM
> > To: [email-masked]; [email-masked]
> > Subject: [Geopriv] Explicit Indication of Location Object Consumer
> >
> > Hi James
> > Hi Brian,
> >
> > do you plan to put additional info into the SIP message to
> > indicate who
> > should consume the Location Object (explicity rather than
> > implicit info)?
> >
> > Here is an example: Assume that SIP UA Alice wants to give
> > Bob location
> > information (via reference). Now, Alice could easily indicate that it
> > wants Bob to resolve the reference and to process the
> > location object.
> > Stating this explicitly would prevent proxies to resolve it and to
> > process the location object.
> >
> > Ciao
> > Hannes
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
>
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
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: "Frank W. Miller" <[email-masked]>
Date: Sat, 03 Jun 2006 20:14:26 -0400

The Web way would be to redirect the request to another address
automatically rather than leaving the address alone and routing it
transparently under the covers.  Think www.whatever going to
www12.whatever in a server farm, or whatever.com going to
us.whatever.com.  You should be doing an end-to-end secure connection to
the original address and then a separate end-to-end secure connection to
the redirected address.

FM

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 03 Jun 2006 19:48:55 -0500

weeeeeell.... "[email-masked]" would be the R-URI in this case, 
wouldn't it?  I think this has to the case since Brian has no knowledge 
which is the closest Pizza-Hut store to contact directly.

Given this, S/MIME should still be the correct way to send location in the 
message (e2e).

A 302 would be the response from [email-masked].

This would necessitate a new INVITE to the new URI given in the 302, but 
not necessarily including location in that INVITE at all.  This is 
interesting... I need to think about how this can be misused/abused.

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 4 Jun 2006 11:12:16 -0400

The problem here is S/MIME.  No one really uses S/MIME with SIP because the
PKI is too hard to deal with.  This case is just as hard as any other case.

I also think PLANNING a B2BUA for this is a bad idea.  B2BUAs are evil.

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Saturday, June 03, 2006 8:49 PM
To: [email-masked]
Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location Object
Consumer

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Jun 2006 14:06:32 -0500

>I also think PLANNING a B2BUA for this is a bad idea.  B2BUAs are evil.

B2BUA's are a reality.  That ship's sailed already.

No one does this function yet (routing a message based on the location of 
the caller), so this is greenfield.  Someone can write an ID intending to 
become a BCP that says this is the RECOMMENDED practice of any organization 
that wants to route based on the location of the caller, since a B2BUA can 
inspect S/MIME bodies because it IS the desination. At that point, I think 
a 3XX is a waste of BW, as the more efficient means of communicating with 
the exact ultimate destination of that [email-masked] R-URI from 
where you are is determined by that server.

Remember, a UA may not have their location by-reference to give to 
[email-masked] to dereference.  That makes the call fail due to not 
having a route; unless you want a less efficient default route that will 
never be right, and cause further delay, and possibly has to be designed 
with user interaction.

If the B2BUA still wants to give a 302 back, it still can, once it's read 
the S/MIME location body.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 5 Jun 2006 16:39:08 -0400

I would strongly prefer to leave this as proxy routes with TLS security.  I
wouldn't want to preclude an endpoint from routing with S/MIME security, but
I don't think that will be common.

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, June 05, 2006 3:07 PM
To: Brian Rosen; [email-masked]
Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; [email-masked]
Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location Object
Consumer

> > > I'm asking this because this seems like it could be a logical
operation
>of
> > > >If I call [email-masked], and I want location based routing,
I
>put
> > > >to do location based routing, it will get the location and send it
off.
>I
> > > >header as the way to get it invoked; we need something else
(directly,
>or
> > > >If I want the endpoint to get it, then I protect it with S/MIME and
no
> > proxy

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 Jun 2006 21:07:53 -0700

A possibly totally irrelevant comment ....

Don't take this as gospel but by best crystal ball gazing at how RAI  
and SEC ADs might look at SIP security items requiring S/MIME ....  
Given the underwhelming implementation and deployment of S/MIME in  
SIP, one would hope there was solutions to achieve some minimal   
level of security that did not rely on S/MIME. If a technique could  
also be secured with S/MIME, or better security could be achieved  
using S/MIME, then making that possible (but not required for the  
minimum) would be fine.

On the topic of proxies looking at bodies (but not modifying them), I  
will point out the end to middle work does some of that.

On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote:

>>>>> proxy will properly ignore it.  The pizza-hut domain is the one  
>>>>> that
>> wants
>>>>> don't need to tell it to do that.  I could imagine a generic  
>>>>> location
>>> based
>>>>> I am less concerned about the security aspects here and more  
>>>>> focused
>> the
>>>>> Typically, it is good to know for a device whether it has to  
>>>>> process
>> the
>>>>>> information (via reference). Now, Alice could easily indicate  
>>>>>> that
>> it

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 9 Jun 2006 23:37:40 -0500

I might point out that in the PSTN today a lot of systems do location
dependent routing without providing the location to the final
destination and I see this as a very useful property. This will be
difficult to perform with S/MIME without a lot of work.

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Saturday, 10 June 2006 2:08 PM
> To: Brian Rosen
> Cc: [email-masked]; 'James M. Polk'; [email-masked]
> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location
> ObjectConsumer
> 
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: David R Oran <[email-masked]>
Date: Sat, 10 Jun 2006 10:44:59 -0400

> difficult to perform with S/MIME without a lot of work.
Let's not confuse the location information provided to intermediaries  
for the purpose of delivering the call where you want, from the  
location information delivered to the ultimate recipient so that the  
application running there can do things with that information. As  
I've argued many times (and I believe the current drafts are in  
alignment with) these two locations "conveyances" need to be carried  
differently (in the case of SIP header versus body), any particular  
SIP message could carry either or both, the confidentiality and  
integrity properties for the two may be quite different, and even the  
content might be different (one or the other might be intentionally  
"fuzzed" to thwart the "target missiles" command).

Can we put this one to bed? Please?

Dave.

P.S. I know those pesky SBCs screw all this up, just like bunches of  
other stuff that one wishes were really end-to-end.

>>>> Object

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Jun 2006 10:47:26 +0200

Hi David,

David R Oran wrote:
> application running there can do things with that information. As  I've 
> argued many times (and I believe the current drafts are in  alignment 
> with) these two locations "conveyances" need to be carried  differently 
> (in the case of SIP header versus body), any particular  SIP message 
> could carry either or both, the confidentiality and  integrity 
> properties for the two may be quite different, and even the  content 
> might be different (one or the other might be intentionally  "fuzzed" to 
> thwart the "target missiles" command).

Would it be acceptable to carry a PIDF-LO in the SIP header? Otherwise 
you always have to create a reference and to let the intermediaries 
fetch the PIDF-LO first. I could imagine that there are cases where this 
could lead to call setup delays.

Ciao
Hannes

>>>>> interesting... I need to think about how this can be
>>
>> misused/abused.
>>
>>>>>
>>>>>>> Question - shouldn't we assume in this example that
>>>>>
>>>>> [email-masked]
>>>>>
>>>>>>>> my location header in the call, and send the call with TLS.  My
>>>>>
>>>>> outbound
>>>>>
>>>>>>>> to do location based routing, it will get the location and send
>>
>> it
>>
>>>> off.
>>>>
>>>>> I
>>>>>
>>>>>>>> routing proxy, but I would not think we would want to mark the
>>>>
>>>> location
>>>>
>>>>>>>> To: Brian Rosen; Hannes Tschofenig; [email-masked];
>>
>> [email-masked]
>>
>>>>>>>> Subject: AW: [Geopriv] Explicit Indication of Location Object
>>>>
>>>> Consumer
>>>>
>>>>>>>>
>>>>>>>> Hi Brian,
>>>>>>>>
>>>>>>> Use [email-masked] for new developments on the application of
>>
>> sip
>>
>>>>
>>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 11 Jun 2006 05:50:12 -0500

Hi Hannes,

This is true, it may lead to some delays, but unless you have multiple
nodes making successive requests then the reference is actually superior
in the circumstance mentioned below as only nodes that are entitled to
location can get it.

If you plonk location in the header then everything that sees the SIP
message can see the location, and this is probably not a good plan. If
you plonk it in the body then usually the end-point can see it. What if
I only want a routing proxy to be able to see my location, and then only
for routing purposes? 

The other case is that a reference allows the node needing location to
request it in the form needed by the application, sending a literal
value form the end-point pre-supposes that the originator knows the
correct form and they may not. The moment negotiations come into play
through the sending of a 424 response code then using a reference has
the same or fewer message exchanges than the use of a literal location
and the added delay argument become somewhat mythical.

There are cases for both reference and literal location representation
though I remain unconvinced about supporting a literal location in the
SIP header.

Cheers
James

> Sent: Sunday, 11 June 2006 6:47 PM
> To: David R Oran
> Cc: Winterbottom, James; Cullen Jennings; [email-masked]; James M. Polk;
> [email-masked]
I've
> >>>>> I also think PLANNING a B2BUA for this is a bad idea.  B2BUAs
are
> >>>>> evil.
> >>>> inspect S/MIME bodies because it IS the desination. At that
point,
> >>>> I think
> >>>> the exact ultimate destination of that [email-masked]
R-URI
> >>>> from
> >>>> having a route; unless you want a less efficient default route
that
> >>>> will
> >>>>> weeeeeell.... "[email-masked]" would be the R-URI in
this
> >>>>> case,
> >>>>>>> Pizza-Hut's SIP infrastructure under the conditions you've
laid
> >>>>>>> out.
> >>>>>>>> If I want the endpoint to get it, then I protect it with
S/MIME
> >>>>>>>> and
> >>>>>>>> If you want to prevent intermediaries to inspect your
location
> >>>>>>>> object
sip
sip
----------------------------------------------------------------------
> >> --------------------------
----------------------------------------------------------------------
> >> --------------------------
> >> [mf2]
> >>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Jun 2006 14:22:52 +0200

Hi James,

I know all the discussions about location-by-value vs. 
location-by-reference. I am also seeing the same aspect showing up in 
other places (e.g., SAML-SIP).

It is obvious that some delay is introduced when you use a reference. 
You certainly have a couple of RTTs and the processing delay to consider.

I would like to carry a PIDF-LO and a SAML assertion in a SIP header.

Winterbottom, James wrote:
> message can see the location, and this is probably not a good plan.

Every SIP proxy sees it, if you use channel security.

  If
> you plonk it in the body then usually the end-point can see it.

If you apply E2E encryption.

> What if

I agree that there are some more sophisticated access control mechanisms 
you can apply. I have no problem to apply these mechanisms if the delay 
does not matter and the threat scenario demands these properties.

Ciao
Hannes

>>>>I might point out that in the PSTN today a lot of systems do
> 
> location
> 
>>>Let's not confuse the location information provided to
> 
> intermediaries
> 
>>>argued many times (and I believe the current drafts are in
> 
> alignment
> 
>>>with) these two locations "conveyances" need to be carried
> 
> differently
> 
>>>might be different (one or the other might be intentionally
> 
> "fuzzed" to
> 
>>fetch the PIDF-LO first. I could imagine that there are cases where
> 
> this
> 
>>>>>Don't take this as gospel but by best crystal ball gazing at how
> 
> RAI
> 
>>>>>level of security that did not rely on S/MIME. If a technique
> 
> could
> 
>>>>>On the topic of proxies looking at bodies (but not modifying
> 
> them), I
> 
>>>>>>Remember, a UA may not have their location by-reference to give
> 
> to
> 
>>>>>>>not necessarily including location in that INVITE at all.  This
> 
> is
> 
>>>>>>>>automatically rather than leaving the address alone and routing
> 
> it
> 
>>>>>>>>>>my location header in the call, and send the call with TLS.
> 
> My
> 
>>>>>>>outbound
>>>>>>>
>>>>>>>
>>>>>>>>>>proxy will properly ignore it.  The pizza-hut domain is the
> 
> one
> 
>>>>>>>>>>that
>>>>>>>
>>>>>>>wants
>>>>>>>
>>>>>>>
>>>>>>>>>>to do location based routing, it will get the location and
> 
> send
> 
>>>>it
>>>>
>>>>
>>>>>>off.
>>>>>>
>>>>>>
>>>>>>>I
>>>>>>>
>>>>>>>
>>>>>>>>>>routing proxy, but I would not think we would want to mark
> 
> the
> 
>>>>>>location
>>>>>>
>>>>>>
>>>>>>>>>>From: Tschofenig, Hannes
> [mailto:[email-masked]]
> 
>>>>>>>>>>>If you have to route on it (emergency or otherwise), then
> 
> you
> 
>>>>>>>>>>>have to send
>>>>>>>>>>>information (via reference). Now, Alice could easily
> 
> indicate
> 
>>>>>>>>>>>that
>>>>>>>
>>>>>>>it
>>>>>>>
>>>>>>>
>>>>>>>>>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: Sun, 11 Jun 2006 09:19:47 -0400

>
> Would it be acceptable to carry a PIDF-LO in the SIP header?  
> Otherwise you always have to create a reference and to let the  
> intermediaries fetch the PIDF-LO first. I could imagine that there  
> are cases where this could lead to call setup delays.

Also, not all UAs have a convenient way to "park" such information.  
Most companies, for example, would have to set up a web server  
outside their firewall for this purpose.

I don't see any particular reason why you couldn't carry a base-64  
encoded version of a PIDF-LO object in a header.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Jun 2006 09:31:08 -0400

We should just have this location/value debate by reference, as in  
"argument 42", "no, argument 17!!!".

However, the access control one is a red herring. If you can supply  
the proxy with a secret to query the LIS, you can also set up a  
public-private key pair for that routing proxy to unwrap the location  
information. (This does not require a public CA.)

In most cases, this is unrealistic. The examples of location-based  
routing include services such as pizza delivery, and there's no way  
(and no mechanism) that I'm going to give PizzaHut a password to my  
LIS. At least with a public key mechanism, I could in theory encrypt  
the PIDF-LO with the public key of Pizza Hut, so that the NSA agent  
sitting at the local VSP won't know where I want my pizza sent.

Thus, if we're having this discussion again, we might want to more  
clearly identify the trust relationships assumed.

On Jun 11, 2006, at 8:22 AM, Hannes Tschofenig wrote:

> Hi James,
>
> I know all the discussions about location-by-value vs. location-by- 
> reference. I am also seeing the same aspect showing up in other  
> places (e.g., SAML-SIP).
>
> It is obvious that some delay is introduced when you use a  
> reference. You certainly have a couple of RTTs and the processing  
> delay to consider.
>
>> for routing purposes? The other case is that a reference allows  
>> the node needing location to
> I agree that there are some more sophisticated access control  
> mechanisms you can apply. I have no problem to apply these  
> mechanisms if the delay does not matter and the threat scenario  
> demands these properties.
>
>>> Otherwise
>> contain privileged, proprietary, or otherwise private  
>> information.  If you have received it in error, please notify the  
>> sender