Re: [Geopriv] IPv6 modification suggestion

"Ammar Salih" <ammar.salih@auis.edu.iq> Mon, 22 October 2012 18:05 UTC

Return-Path: <ammar.salih@auis.edu.iq>
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 9AFE421F892E for <geopriv@ietfa.amsl.com>; Mon, 22 Oct 2012 11:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.228
X-Spam-Level:
X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 VAIM9qUVldTg for <geopriv@ietfa.amsl.com>; Mon, 22 Oct 2012 11:05:45 -0700 (PDT)
Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id 39E9F21F897A for <geopriv@ietf.org>; Mon, 22 Oct 2012 11:05:44 -0700 (PDT)
Received: from mail-ee0-f70.google.com ([74.125.83.70]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUIWK+MPeDielcYOPG7xBQnN0TLIsxe2Z@postini.com; Mon, 22 Oct 2012 11:05:45 PDT
Received: by mail-ee0-f70.google.com with SMTP id b57so2582911eek.1 for <geopriv@ietf.org>; Mon, 22 Oct 2012 11:05:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=+3Hdl6q6IYSwovsXpmMlBLb3Fohxz3VNzT4RE401Gq4=; b=hD97UU8AqMvKNei1dcPmxW98Uc27QwhwAk3SPLsg/m0YLU1t9aw9ULb9HSqS88wJvs 1xw143tGJLUeix0WeIeT+wRp7wq+zFabEQnBb2aplzzwqdDUp/SG7juhVQsMzEvhgV1C YmIU6PlHNUIAEoZcioKiB9r2Z/8VtR5K06vUeNsd9EZakiLpIhO9e5buzDMFqMwZ/0i9 S9mWoBZNmoxOobMrT+LFUWjue6bc7Y4JCKmVERYUxHEE7CmdNcG/jo4jGSHLMlJ/uwsX ZF9eGhyMVJGjty6TqzBgHXxPhFjIJE1U7BOsrTMgIeEoaj5x5J+0oQc3s5L7VKe5N91g FMLg==
Received: by 10.204.3.214 with SMTP id 22mr2912380bko.108.1350929143078; Mon, 22 Oct 2012 11:05:43 -0700 (PDT)
Received: by 10.204.3.214 with SMTP id 22mr2912375bko.108.1350929142859; Mon, 22 Oct 2012 11:05:42 -0700 (PDT)
Received: from AMMARSALIH ([95.159.75.98]) by mx.google.com with ESMTPS id v14sm4363535bkv.10.2012.10.22.11.05.38 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 11:05:41 -0700 (PDT)
From: Ammar Salih <ammar.salih@auis.edu.iq>
To: 'Richard Barnes' <rbarnes@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> <78A28703-EFED-44B9-BC93-C0CF8729B1CB@bbn.com>
In-Reply-To: <78A28703-EFED-44B9-BC93-C0CF8729B1CB@bbn.com>
Date: Mon, 22 Oct 2012 21:05:32 +0300
Message-ID: <50858af5.0e0ccc0a.2abc.6ca3@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac2wVtWLtTzi891OT5SOYKnv6s4CnQAIIt5A
Content-Language: en-us
X-Gm-Message-State: ALoCoQkY1FQAGtWca0STYC48jwONpGsK+IZKtsjgZIEE/EnBhHIN+Mq+EKd98nlcrSs0HLovQ6j5ifc11tsDNUPA7UTNAwZRoErCs0nO0BPYypUmBvDiTwkY6HqxvrwSiGjjns0q2zVpBMgsTPZW9SkkcdJftFlYcA==
X-Mailman-Approved-At: Mon, 22 Oct 2012 11:24:37 -0700
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 18:05:47 -0000

Hello Richard, 

> 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.

You could have the router modify the location field anyways, just like L2/L3
QoS fields, if you don't trust the host, no need for encryption or security,
plus ACL is not only for security, it could be used for routing, QoS ..etc,
so the host will not always has the motivation to hack the location field.


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

For shortest path maybe yes, metric is important, not for policy-based
routing, for example if you would like to do location-based routing, like,
routing traffic coming from France to google.fr or youtube traffic to France
youtube cashing server, there could be so many other applications.


> But prior proposals for geolocation-based routing in the IETF (going 
> back to 1996) have failed [2][3][4].  

I didn't go through those documents, but from the titles I would assume that
they failed because they wanted to replace IP address with GPS locations, or
create GPS-based addressing scheme, ignoring the "mobility" factor which is
a huge deal in this discussion. I am suggesting to keep the IP address and
attach GPS dynamically.

> What would be the use case for geography-based routing?  Enforcement of
local 
> policies?

implementing regulations, for example, certain regions does not allow VoIP
calls over GSM/GPRS network. ITEF IPv6 team suggested that it is better to
configure the policy on the router, I suggested that using "Mobile BTS" for
example makes static configuration a nightmare, and implementing
location-based policy makes the configuration more dynamic and easier to
implement. 

> 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.

Unfortunately, I did not, it was like 10 - 15 emails with IPv6 team.

Thanks,
Ammar


-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com] 
Sent: Monday, October 22, 2012 4:12 PM
To: Ammar Salih
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] IPv6 modification suggestion

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
>