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

["James M. Polk" <[e-mail]>]

At 02:50 PM 7/22/2010, Alissa Cooper wrote:
>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?

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore