Re: [Geopriv] IPv6 modification suggestion

Richard Barnes <rbarnes@bbn.com> Mon, 22 October 2012 13:12 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: geopriv@ietfa.amsl.com
Delivered-To: geopriv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D49D21F8B8C for <geopriv@ietfa.amsl.com>; Mon, 22 Oct 2012 06:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.592
X-Spam-Level:
X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BUX6WKnL1vG for <geopriv@ietfa.amsl.com>; Mon, 22 Oct 2012 06:12:05 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 629D221F88C1 for <geopriv@ietf.org>; Mon, 22 Oct 2012 06:12:05 -0700 (PDT)
Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:55162) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1TQHnY-000FEz-1F; Mon, 22 Oct 2012 09:12:04 -0400
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Richard Barnes <rbarnes@bbn.com>
In-Reply-To: <5084783a.a960b40a.0296.1ca1@mx.google.com>
Date: Mon, 22 Oct 2012 09:12:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <78A28703-EFED-44B9-BC93-C0CF8729B1CB@bbn.com>
References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <D1A762E7-1132-4C09-8096-9B10D145811D@gmail.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <6CBCC380-E419-443C-88B1-17C85105E648@bbn.com> <5084783a.a960b40a.0296.1ca1@mx.google.com>
To: Ammar Salih <ammar.salih@auis.edu.iq>
X-Mailer: Apple Mail (2.1283)
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] IPv6 modification suggestion
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2012 13:12:06 -0000

Hi Ammar,

I think that if you think through your examples more carefully, you'll see that an IPv6 extension header for geolocation doesn't really solve the problem you want.  

For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL.  If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header.  The routing community is already having enough trouble implementing signatures on BGP messages [1]; a signature on every packet would probably not be viable.  It would make the router do about as much as a VPN concentrator.

For location-based routing protocols: Why would you want this?  Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency.  People will go to great lengths to reduce topological distances (CDNs, cables under the arctic).  But prior proposals for geolocation-based routing in the IETF (going back to 1996) have failed [2][3][4].  What would be the use case for geography-based routing?  Enforcement of local policies?

I am also not as optimistic as you are about GPS being everywhere.  For example, GPS does a really poor job inside of buildings.  That's why we invented GEOPRIV in the first place, to help out where GPS fails! 

Nonetheless, if you have written a paper or Internet-draft about your proposed extension to IPv6, I would be glad to read it and provide comments.

Cheers,
--Richard

[1] <http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05>
[2] <http://tools.ietf.org/html/rfc2009>
[3] <http://tools.ietf.org/html/draft-mangione-ipv6-gps-alt-00>
[4] <http://tools.ietf.org/html/draft-hain-ipv6-geo-addr-02>


On Oct 21, 2012, at 6:33 PM, Ammar Salih wrote:

> Hello Richard,
> 
> My concern is that IETF is integrating location field in each application
> separatly, like GEOPRV, SIP Geo header .. etc, plus implementing application
> layer protocol is feasible in application servers only, network devices
> won't have the cabability to understand the feature. I've given few examples
> to IPv6 team regarding geo-location involvement, one would be location-based
> ACL, another would be location-based routing protocol.
> 
> I anticipate that one day, layer 3-7 location-based policies will be
> integrated into one header, as GPS devices becoming smaller and accurate
> cooedinates are higly required.
> 
> Thanks,
> Ammar
> 
> 
> 
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com] 
> Sent: Friday, October 19, 2012 3:46 PM
> To: Ammar Salih
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] IPv6 modification suggestion
> 
> Hi Ammar,
> 
> Thanks for your interesting use case.  Adaptation of services based on
> geolocation is something that GEOPRIV is intended to support.  One example
> you might consider is ECRIT [1].  In that system, the end device or its
> proxy discovers how to direct an emergency call based on the caller's
> geolocation. 
> 
> Is your concern really at layer 3, or is it specific to certain
> application-layer protocols?  For example, if you are primarily concerned
> with HTTP / web filtering, it might be that what you really want is an HTTP
> header for geolocation, similar to the SIP Geolocation header [2].  There
> have been proposals for such an HTTP header before, and there was not much
> interest.  But if you think there would be people interested in using this
> header, then it could be something that we could work on in GEOPRIV.  
> 
> Keep in mind that in order to make these things useful, though, the end host
> has to actually populate the field.  So you'll need to convince either OS
> vendors (for an IPv6 header) or browser vendors (HTTP header) that this is a
> good idea.
> 
> Cheers,
> --Richard
> 
> 
> [1] <http://tools.ietf.org/ecrit/>
> [2] <http://tools.ietf.org/html/rfc6442>
> [3] <http://tools.ietf.org/html/draft-thomson-geopriv-http-geolocation-00>
> 
> 
> On Oct 18, 2012, at 4:03 PM, Ammar Salih wrote:
> 
>> Hello everyone, I had a brief look at GEOPRIV and I was very much 
>> impressed, There has been so much work done by this amazing group!
>> 
>> At the same time, I would like to raise my concern regarding the http 
>> location request which will not be detected by layer-3 devices 
>> (Routers), I am anticipating that in the future, GPS capability will 
>> be added to the router itself (just like smart phones) and packet 
>> marking and classification based on geo-location will be required.
>> 
>> QoS, firewall and routing based on geo-location will be highly 
>> demanded when mobile routers move from one geo-location to another 
>> which has different regulations/electronic laws.
>> 
>> Here is an example, if your router is within city-X and this city has 
>> very good electronic and copyright laws, then users will have relaxed 
>> network security settings, but what if the very same router moved to 
>> city-Y which according to its law, certain websites should be blocked 
>> (like facebook in china for example) .. these rules based on 
>> geographic location won't be feasible unless the mobile router has a 
>> GPS and can read/write coordinates to layer-3 packets.
>> 
>> Best,
>> Ammar
>> 
>> 
>> -----Original Message-----
>> From: Ammar Salih [mailto:ammar.salih@auis.edu.iq]
>> Sent: Thursday, October 11, 2012 11:41 AM
>> To: 'Bob Hinden'
>> Cc: 'ipv6@ietf.org'
>> Subject: RE: IPv6 modification suggestion
>> 
>> Hello Bob,
>> 
>>> That said, I don't think it is a good idea to add GPS position to 
>>> every
>> IPv6 header.  It would add a lot of overhead.
>> 
>> It does not have to be in every IPv6 header, only when there is 
>> location update, also it can be included in the first header (just 
>> like RTP and cRTP)
>> 
>> 
>> 
>>> there are many privacy related issues (as others have pointed out).
>> 
>> This can be set manually in case of any privacy concerns, just like 
>> other header's information like IP address.
>> 
>> 
>> 
>>> An alternative would be to create a application layer protocols that 
>>> could
>> request and send GPS positions.  
>> 
>> Sounds awesom, but in this case all webpages, phone applications, 
>> server side scripting languages ... etc have to be modified to support 
>> the new application protocol. Not mensioning that layer 3 devices 
>> (like routers) won't be able to support the feature, let's say in the 
>> feature you want to do dynamic routing based on geo location.
>> 
>> 
>> In anycase, I still feel quite interested about the new layer 7 
>> protocol, will try to go through the GEOPRIV documentation this 
>> weekend in order to get more details.
>> 
>> Thank you for your kind response,
>> Ammar
>> 
>> 
>> 
>> -----Original Message-----
>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
>> Sent: Thursday, October 11, 2012 6:37 AM
>> To: Ammar Salih
>> Cc: Bob Hinden; ipv6@ietf.org
>> Subject: Re: IPv6 modification suggestion
>> 
>> Ammar,
>> 
>> On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote:
>> 
>>> Hello Dears,
>>> 
>>> I would like to suggest adding GPS coordinates to IPv6 header, as you 
>>> know
>> the current way of determining the location of the IP address is 
>> through the IP registration, which is not very accurate as it depends 
>> on how the ISP registers it's IP subnets, which is normally done based on
> country/city.
>> 
>> I agree with you that IP addresses are not very reliable as a means of 
>> determining geographic location.  That said, I don't think it is a 
>> good idea to add GPS position to every IPv6 header.  It would add a 
>> lot of overhead, there are many privacy related issues (as others have 
>> pointed out), it doesn't need to be in every packet.  An alternative 
>> would be to create a application layer protocols that could request 
>> and send GPS positions.  That is a better way to to deal with the 
>> privacy issues and the GPS position would only need to be sent when
> desired or when requested.
>> 
>> The GEOPRIV working group is doing some work in this area.  See:
>> 
>> http://datatracker.ietf.org/wg/geopriv/charter/
>> 
>> Bob
>> 
>> 
>>> 
>>> Getting more accurate locations will enhance many services provided 
>>> by the
>> web, like targeted commercials (for example, I can get Ads regarding 
>> restaurants available in my neighborhood instead of all restaurants in 
>> the city), another good example would be webpage's language, my 
>> language will be detected more accurately based on my exact area 
>> rather than my countery, as there are many countries with more than one
> popular language.
>>> 
>>> Maps, navigation, emergency calls and many other services will also 
>>> get
>> enhanced with accurate locations.
>>> 
>>> I hope you will find my suggestion beneficial, and looking forward to
>> hearing from you.
>>> 
>>> 
>>> Best,
>>> 
>>> Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead - 
>>> Voice and Data Support Services
>>> 
>>> Mob: +964 (0) 770 533 0306
>>> Office: +964 (0) 53 511 2020  -  Ext. 2221
>>> Email: ammar.salih@auis.edu.iq
>>> The American University of Iraq - Sulaimani
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>