Subject: [sipcore] Bad Location Information in draft-ietf-sipcore-location-conveyance-03

From: Alissa Cooper <[email-masked]>
Date: Thu, 22 Jul 2010 20:50:06 +0100

Section 4.2 of draft-ietf-sipcore-location-conveyance-03 says:

    A SIP intermediary can also reject a location it receives from a
    Target when it understands the Target to be in a different location.
    The proper handling of this scenario is for the SIP intermediary to
    include the proper location in the 424 Response.  This SHOULD be
    included in the response as a MIME message body (i.e., a location
    value), rather than as a URI; however, in cases where the
    intermediary is willing to share location with recipients but not
    with a user agent, a reference might be necessary.

Does this leave the Target's ability to spoof its location up to the  
discretion of the SIP intermediary?

Thanks,
Alissa

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Jul 2010 16:09:13 -0500

>discretion of the SIP intermediary?

Alissa - I'm not 100% I understand the direction of your question - 
but here is my first try.

If you're asking that an intermediary *can* prevent a Target from 
lying, the answer is yes.

why is this prevented? Because the intermediary could be literally 
standing in the way of this message's progressing further into the 
network towards the destination, and believes (not consciously of 
course) that it knows better where the Target is than what is in the 
SIP request.  The intermediary has a couple of alternatives:

- it could send a 424 response with the only location it will accept 
in a subsequent SIP request from that Target, or

- it could compose a dual location PIDF and return it to the Target 
to have it send in the subsequent SIP request, or

- it could overwrite the existing location, unbeknownst to the 
Target, and deliver that to the destination UAS.

The work around is to not have that intermediary in the signaling 
path in any subsequent SIP request - but only works *if* the Target 
learns that the intermediary is doing this in the first place, which 
wouldn't be the case (easily) if the intermediary is just overwriting 
the Target's location.

I don't see any other way around this.

If we state that this MUST NOT happen, that'll fly in the face of 
what IMS is defining where "UEs (i.e., UACs) aren't to be trusted 
with this kind of information", as just one example.

Did I get your question right (even if you did or did not like the answer)?

James

>Thanks,
>Alissa
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 22 Jul 2010 19:30:26 -0400

Like James notes, intermediaries have always had the power to block  
any request they please (e.g., with the 401 Unauthorized header).  In  
the case of location, the concern you note is just one more motivation  
for proxies to keep their hands off my INVITE; I don't think there's a  
technical solution.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 23 Jul 2010 14:33:19 +0100

On Jul 22, 2010, at 10:09 PM, James M. Polk wrote:

> wouldn't be the case (easily) if the intermediary is just  
> overwriting the Target's location.
>

Yep, and knowing the alternatives is helpful. I just wanted to make  
sure I was understanding right.

Thanks,
Alissa