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

Alissa Cooper <acooper@cdt.org> Fri, 23 July 2010 13:33 UTC

Return-Path: <acooper@cdt.org>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433163A6861 for <sipcore@core3.amsl.com>; Fri, 23 Jul 2010 06:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.767
X-Spam-Level:
X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NET0Q+VGOOU0 for <sipcore@core3.amsl.com>; Fri, 23 Jul 2010 06:33:54 -0700 (PDT)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 910033A686B for <sipcore@ietf.org>; Fri, 23 Jul 2010 06:33:29 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 23 Jul 2010 09:33:20 -0400
Message-Id: <D3FC34EF-D8FC-45D9-9140-499C4BAFDD64@cdt.org>
From: Alissa Cooper <acooper@cdt.org>
To: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <201007222109.o6ML9EXv011843@sj-core-3.cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 23 Jul 2010 14:33:19 +0100
References: <A29736AF-DAF4-4BB4-B13D-16DEE3EDF123@cdt.org> <201007222109.o6ML9EXv011843@sj-core-3.cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Bad Location Information in draft-ietf-sipcore-location-conveyance-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2010 13:33:57 -0000

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

> 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)?
>

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

Thanks,
Alissa

> James
>
>
>
>> Thanks,
>> Alissa
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>