Re: [Geopriv] RE: Strawman Proposal

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 13 March 2007 21:16 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 1HREMP-0001dC-0g; Tue, 13 Mar 2007 17:16:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREMN-0001d3-Tp for geopriv@ietf.org; Tue, 13 Mar 2007 17:16:43 -0400
Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREMM-0005dW-Js for geopriv@ietf.org; Tue, 13 Mar 2007 17:16:43 -0400
Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2DLGZwU012281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2007 17:16:36 -0400 (EDT)
In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF102957DA6@AHQEX1.andrew.com>
References: <E51D5B15BFDEFD448F90BDD17D41CFF102957DA6@AHQEX1.andrew.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Geopriv] RE: Strawman Proposal
Date: Tue, 13 Mar 2007 17:17:18 -0400
To: "Winterbottom, James" <James.Winterbottom@andrew.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: a2c12dacc0736f14d6b540e805505a86
Cc: GEOPRIV <geopriv@ietf.org>, "Dawson, Martin" <Martin.Dawson@andrew.com>, Marc Linsner <mlinsner@cisco.com>
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

On Mar 13, 2007, at 4:51 PM, Winterbottom, James wrote:

> Hi Hannes,
>
>
>> * We don't do Location Signing at all.
>> * Access networks distribute location information to the end host  
>> at a
>> granularity that allows location based routing (unsigned). For most
>> countries this is in fact trivial.
>
>
> [AJW] My discussions with carriers and infrastructure providers  
> seems to
> suggest that obtaining location information to provide to end hosts is
> going to be far from trivial. When confronted with this hurdle I am  
> not
> so sure that adding signing is that much more work.

I agree with Hannes that location granularity matters. Having a  
single LO for the whole DSLAM (or DHCP server) that says "XYZ County"  
is a whole lot easier than tracking the wiring panel changes as lines  
get moved.

Signing is not the big deal - getting valid CA-certified signatures  
is. We all know how many web servers have bogus, expired or self- 
signed certificates, and not just Joe's Barber Shop and Delicatessen.

Take a large campus with thousands of offices. Unless you have a  
fairly elaborate delegation mechanism, somebody externally will have  
to sign for each and every room. This means that the organization has  
to operate a CA that is trusted by the proposed VESA entity, for  
example. We can't even get delegation to work within Internet2 and  
Columbia.




>
> [AJW] It is not clear to me how authenticating millions of users and
> their multitude of identity mechanisms is any less daunting than
>

We have such a mechanism, e.g., within IMS, namely P-Asserted-ID,  
which is very widely deployed, from what I can tell. Or the SIP  
identity mechanism, although that seems to just start getting  
traction. The PSAP wouldn't care whether and how the VSP verified the  
customer identity; it just gets a single client cert from the VSP in  
a TLS connection.

You probably missed the discussion on this years ago, but your  
concern and the perceived difficulties of a global PKI motivated the  
current mechanism, as it only requires what customers must have  
already, namely a shared secret with their VSP, and web-style cross- 
provider trust with a single cert  for each provider.


> providing accreditation to potentially thousands of access network
> providers. But perhaps I am missing the point. That said, if you  
> couple
> this with signed location then you have the whole gamut. See location
> dependability draft
> http://tools.ietf.org/html/draft-thomson-geopriv-location- 
> dependability-
> 00
>
>>
>> PS: I also believe that the PSAP operator would accept calls that
> don't
>> have any location attached to it. How many calls today have location
>> information available? Do we have some statistics about it?
>>
>
> [AJW] All emergency calls in the world have some degree of location
> provided (inferred), though in some cases this may not be  
> fantastically
> accurate, country level. In the United States for wireline it is based
> on the calling line ID, and either an ESRD (roughly representing a  
> cell)
> or an ESRK (representing a rough calling area) for wireless.
>
> Perhaps, like some other working groups we need to make the  
> distinction
> between support and implement. I am asking that the requirements  
> include
> support for it, I think that implementation will be something that
> jurisdictions have the option to do or not.

This doesn't quite work, given that phones need to work universally.  
I don't want to buy a phone in Prague, say, that suddenly can't make  
an emergency call in New York city.

Henning

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