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 >
- [sipcore] Bad Location Information in draft-ietf-… Alissa Cooper
- Re: [sipcore] Bad Location Information in draft-i… James M. Polk
- Re: [sipcore] Bad Location Information in draft-i… Richard L. Barnes
- Re: [sipcore] Bad Location Information in draft-i… Alissa Cooper