Re: [Geopriv] Location in SIP and "retransmission-allowed"

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 01 May 2007 23:41 UTC

Return-path: <geopriv-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1yJ-0004Oz-N9; Tue, 01 May 2007 19:41:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1yI-0004JY-0O for geopriv@ietf.org; Tue, 01 May 2007 19:41:26 -0400
Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj1yG-0001Qi-PK for geopriv@ietf.org; Tue, 01 May 2007 19:41:25 -0400
Received: from [160.39.244.242] (dyn-wireless-244-242.dyn.columbia.edu [160.39.244.242]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l41Nf8IW018552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 May 2007 19:41:09 -0400 (EDT)
In-Reply-To: <4637BB41.2070505@bbn.com>
References: <886DD03D15173C43BCE98EA662A0101A0221A8BD@stntexch12.cis.neustar.com> <p06240601c25d26b98db8@[129.46.226.38]> <396DA4D1-9D1E-4081-82F7-05460F5B0F68@cs.columbia.edu> <p06240606c25d427f1018@[129.46.226.38]> <89CF892B-35C0-4124-AB18-F28569159442@cs.columbia.edu> <p06240607c25d491a9c79@[129.46.226.38]> <74195101-8447-4451-8532-6AC0B3A9155D@cs.columbia.edu> <4637BB41.2070505@bbn.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <C414581C-9D60-4CD8-8870-586F93593E41@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"
Date: Tue, 01 May 2007 19:42:13 -0400
To: Richard Barnes <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.752.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Ted Hardie <hardie@qualcomm.com>, geopriv@ietf.org, "Rosen, Brian" <Brian.Rosen@neustar.biz>
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Errors-To: geopriv-bounces@ietf.org

Your example seems to assume that the flag adds privacy by being set.  
Unfortunately, that's not the case.

In your example, the privacy-conscious (emergency) caller will say  
'no'. Let's assume that we have the standard two-stage routing (local  
+ emergency services network). The call reaches the ESN and the flag  
indicates "sorry, no LoST". In this case, the only alternative is to  
fail the call. It's not like the LoST lookup is some optional frill  
for this call. Thus, the call will fail and, if you're lucky, the UA  
will retry, presumably after displaying a warning message to the user  
to the effect that no call will go through until they click off on  
the privacy release. The outcomes are thus exactly the same with or  
without the flag: a successful call, but no additional privacy, or no  
call.

The hypothetical disclosure of information you mention is in no way  
prevented by having this flag set to 'no', even if all entities in  
the call path observe the flag. The correct way to protect privacy is  
to privacy-protect the signaling channel or, if you're truly  
paranoid, do bogus LoST queries to obfuscate real ones.

The same is true for the pizza call, so this does not depend on the  
specific example.

Henning

On May 1, 2007, at 6:12 PM, Richard Barnes wrote:

> Perhaps location information, by itself, devoid of all context, has  
> no privacy implications.  But in practice, there's always context.
>
> If I see a LoST query go by containing a location, I can infer that  
> there's something at that location, and probably something capable  
> of calling for emergency services.  If I want to jam emergency  
> calls in an area, LoST queries give me enough information to know  
> where to put my jammers.  Or if I'm watching a stream of periodic  
> LoST queries, and I see one go outside the usual pattern, then I  
> know the location of someone making an emergency call.
>
> I have to agree with Ted: No means no, and when there are  
> exceptions, they should be made explicit.
>
> --Richard
>


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv