Re: [Geopriv] Adding GPS location to IPv6 header
Mark Andrews <marka@isc.org> Wed, 21 November 2012 07:05 UTC
Return-Path: <marka@isc.org>
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 57F2F21F87E1; Tue, 20 Nov 2012 23:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HS_INDEX_PARAM=0.001]
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 QV-Qu0aTJnMC; Tue, 20 Nov 2012 23:05:45 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EC21F8450; Tue, 20 Nov 2012 23:05:44 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7C7C7C985C; Wed, 21 Nov 2012 07:05:34 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3c0e:404f:1fe2:ca82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CA448216C81; Wed, 21 Nov 2012 07:05:33 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A53E42B7AEA8; Wed, 21 Nov 2012 18:05:29 +1100 (EST)
To: Ammar Salih <ammar.salih@auis.edu.iq>
From: Mark Andrews <marka@isc.org>
References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <F57BCAEE8C344E948B5A553E5A8EE884@OfficeHP> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> <BBE26B40367FDD4985430D1DE12B6DB00E6FFD8F@xmb-rcd-x08.cisco.com> <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com>
In-reply-to: Your message of "Wed, 21 Nov 2012 01:03:06 +0300." <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com>
Date: Wed, 21 Nov 2012 18:05:29 +1100
Message-Id: <20121121070529.A53E42B7AEA8@drugs.dv.isc.org>
X-Mailman-Approved-At: Wed, 21 Nov 2012 06:02:17 -0800
Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker (fred)'" <fred@cisco.com>
Subject: Re: [Geopriv] Adding GPS location to IPv6 header
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: Wed, 21 Nov 2012 07:05:57 -0000
In message <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com>, "Ammar Salih" writes: > > As to this schema mentioned below, embedding location info in packet > headers is potentially exposing the location coordinate to "snoopers > > Ok, I would like to shed some light regarding privacy issue: > > First, user should have the option of not sending location updates. > > Second, user will be routed through an ISP, if we don't trust the ISP then I > can assure you that ISP can get much more information than physical > location, any un-encrypted traffic -which is the majority- can be analyzed > at the ISP level (up to layer-7). There are LOTS of ISPs between the client and the destination. Most of these can get nothing about your location. > Other than ISP, the sniffer could be connected to the same layer-2/layer-3 > device as mine, in this case I would worry about > usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not > location as the sniffer in this case is mostly sitting at the same physical > location as mine. > > Thanks > Ammar > > > > -----Original Message----- > From: John Pickens (jopicken) [mailto:jopicken@cisco.com] > Sent: Tuesday, November 20, 2012 11:48 PM > To: Carl Reed; Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: RE: [Geopriv] Adding GPS location to IPv6 header > > I've been monitoring this thread. In the IETF the objective is to respect > privacy of correlation of IP address to location metadata. Essentially as > mentioned below the client device receives it in the extant protocols. The > consumer can provide authorization as to the granularity of location that is > visible to other entities. As to this schema mentioned below, embedding > location info in packet headers is potentially exposing the location > coordinate to "snoopers". If encrypted, then.... > > Thoughts of others? > > J > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf > Of Carl Reed > Sent: Tuesday, November 20, 2012 12:15 PM > To: Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Gotcha - thanks! > > Carl > > > -----Original Message----- > From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 1:12 PM > To: Carl Reed > Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > References for DHCP location: > <http://tools.ietf.org/html/rfc4776> > <http://tools.ietf.org/html/rfc6225> > > If I understand the proposal correctly, this is an orthogonal problem to the > one DHCP location solves. > > DHCP geolocation sends location from the DHCP server to the end host. This > IPv6 option would send location from a host to the destination of a packet > (e.g., a server) and intermediate routers. > > > > On Nov 20, 2012, at 2:52 PM, "Carl Reed" <creed@opengeospatial.org> wrote: > > > Hi - > > > > I asked this question before and did not get a response (maybe because > > my question was off base). > > > > There is a location extension for DHCP. This extension is consistent > > with other location object definitions used in the IETF as well as > > what is used and specified in various ISO, OGC, OASIS and other standards. > > > > Why not use the DHCP location extension? Why define yet another > > location element for IPv6? > > > > Thanks > > > > Carl Reed, PhD > > CTO > > OGC > > > > > > -----Original Message----- From: Richard L. Barnes > > Sent: Tuesday, November 20, 2012 11:49 AM > > To: Ammar Salih > > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > > > Hi Ammar, > > > > I have read your draft. From what I can tell, it is just a summary of > > the arguments in this thread. It would be more helpful if you could > > add a level of technical detail to help people understand. I would > > want to see at least: > > 1. The format of the IPv6 option > > 2. Where it is to be added to / removed from a packet 3. Requirements > > for routers / hosts 4. Privacy considerations 5. Security > > considerations > > > > Also, it will be slightly easier to read if you use some of the > > standard tools for authoring Internet drafts. See, for example: > > <http://tools.ietf.org/> > > > > Technically speaking, I'm not yet convinced that this option is very > > useful, but it does not seem to me that this option would be harmful > > to the network, only possibly the privacy of users. In specifying the > > privacy mechanisms in your detailed description, I would suggest that > > you make this mechanism "opt-in" by end hosts. For example, you could > > have an all-zero geolocation option indicate that a host wishes to > > disclose its location, but doesn't know its geolocation to put in the > > option; then you could require that a router SHOULD NOT populate this > > option unless an all-zero geolocation option is already present > (indicating consent). > > > > It would also be helpful to clarify how this option would relate to > > other similar options, such as the line identifier option: > > <http://tools.ietf.org/html/rfc6788> > > > > Hope this helps, > > --Richard > > > > > > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih <ammar.salih@auis.edu.iq> wrote: > > > >> Hello Fred, > >> > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> Appreciate it, the first draft has been submitted already > >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?in > >> clude_text=1 > >> > >> > >> One consideration you should take in view is that the IPv6 header is > >> not encrypted, so information found in it is globally readable. If > >> there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you will > >> want to put it in the application layer (above the transport, guarded > >> by IPsec or TLS), not the network layer. > >> > >> I have suggested few solutions to cover the privacy concern and also > >> why I am suggesting the network layer instead of the application > >> layer, you could find them included in the internet draft above. > >> > >> > >> I would expect that 6man might tell you that the IPv6 header has one > >> primary purpose, which is to conduct a datagram from the sender's > >> system to the intended receiver's system; if the data doesn't help > >> achieve that, it's probably in the wrong header. > >> > >> I agree, also from OSI perspective, I would think twice before > >> including location field into network layer, then again, it's the > >> only layer that makes the field useable to routers. > >> > >> > >> > >> Thanks, > >> > >> Ammar > >> > >> > >> > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Friday, November 16, 2012 6:05 AM > >> To: Ammar Salih > >> Cc: <ipv6@ietf.org>; <geopriv@ietf.org> > >> Subject: Re: Adding GPS location to IPv6 header > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> One consideration you should take in view is that the IPv6 header is > >> not encrypted, so information found in it is globally readable. If > >> there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you will > >> want to put it in the application layer (above the transport, guarded > >> by IPsec or TLS), not the network layer. In fact, I would expect that > >> 6man might tell you that the IPv6 header has one primary purpose, > >> which is to conduct a datagram from the sender's system to the > >> intended receiver's system; if the data doesn't help achieve that, it's > probably in the wrong header. > >> > >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > >> > >> > >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, > >> I've written the below document to summarize few ideas. > >> > >> Is it possible to publish this on IETF website? even if it will not > >> be implemented now, at least for documentation and requesting > >> feedback from the community. > >> > >> > >> > >> Many thanks. > >> > >> Ammar > >> > >> > >> > >> > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> October 30, 2012 > >> Title: IP-LOC > >> > >> > >> > >> Adding GPS location to IPv6 header > >> > >> Abstract: > >> ========= > >> > >> This document describes IP-LOC, an extension to IPv6 header which > >> suggests adding GPS coordinates, as the current method of determining > >> the location of IP traffic is through IP address registration > >> database, which is not very accurate as it depends on how the ISP > >> registers its IP subnets, that is normally done in a country/city format. > >> > >> It also assumes 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 > >> required when mobile routers move from one geo-location to another > >> which has different policy. > >> > >> > >> > >> > >> > >> Benefits of adding GPS location to IPv6 header (IP-LOC) > >> ======================================================= > >> > >> > >> Web Services: 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 neighborhoods > >> 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 area rather than my country, as there are many countries > >> with more than one popular language, not mentioning that many ip > >> registrations does not even reflect the traffic originating country. > >> > >> ------------------------------- > >> > >> Information accuracy and control: Nowadays, locations are assigned to > >> IP addresses without user awareness or control, every time a user > >> performs ip-lookup query the response would be different based on how > >> the ISP has registered this IP subnet, IP-LOC suggests making > >> locations more accurate and controllable through OS and network > >> devices, exactly like IP addresses (user can change his/her IP > >> address, but router can also modify the header information - in case it's > required). > >> > >> ------------------------------- > >> > >> > >> Routing: Policy based routing, based on geo-location, like routing > >> predefined traffic through certain server or path, for different > >> purposes (security, manageability, serviceability like choosing > >> language, or routing traffic to specific cashing or proxy server based on > country .. > >> etc) > >> > >> ------------------------------- > >> > >> > >> Copyright law: It happens when certain media/web content is not > >> allowed in certain countries due to copyright law, the current method > >> of determining locations is not accurate at all, on other hand, If > >> layer-7 application to be used then the user might be able to > >> manipulate the location field, in this case (if it's required in > >> future) the ISP can tag traffic with country/city more accurately as > >> traffic passes through ISP's boarder routers. > >> > >> ------------------------------- > >> > >> Maps, navigation, emergency calls and many other services will be > >> also enhanced with accurate locations. > >> > >> > >> > >> > >> > >> CURRENT ARGUMENTS AGAINST THIS IDEA: > >> ======================================== > >> > >> "Adding GPS position to every IPv6 header would add a lot of overhead" > >> > >> Response: It does not have to be in every IPv6 header, only when > >> there is location update, also the host should have the option of not > >> to send location updates. > >> > >> ------------------------------- > >> > >> "What about privacy?" > >> > >> Response: User should have the option of not sending location updates. > >> User should also have the ability to set location to all zeros, in > >> this case no router will modify the location field and user loses the > >> location-based services. > >> > >> If it's router-to-router link, then no need to be worried about > >> privacy as such information usually configured on a separate network. > >> > >> -------------------------------- > >> > >> "a good alternative would be to create application layer protocols > >> that could request and send GPS positions" > >> > >> Response: the layer-7 location request will not be detected by > >> layer-3 devices (Routers), I am assuming that in the future, GPS > >> capability will be added to the router itself (just like smart > >> phones), features like packet marking and classification based on > >> geo-location will be required to enforce the new geo-location policies. > >> > >> -------------------------------- > >> > >> "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" > >> > >> Response: For shortest path maybe yes, hops or latency is important, > >> not for policy-based routing, in our case you might want to do > >> location-based routing, like, routing traffic coming from French > >> speaking users (in multi-language country like Canada) to google.fr > >> > >> --------------------------------- > >> > >> "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" > >> > >> Response: You could have the router modify the location field > >> anyways, just like L3 QoS fields, if you don't trust the host, so no > >> need for encryption or security, additionally, ACL is not only for > >> security, it could be used for routing, QoS ..etc, so the host will > >> not always has the motivation to manipulate the location field. > >> > >> --------------------------------- > >> > >> "Why can't you simply implement rules related to geo-locations > >> statically on the network device (router, firewall .. etc)?" > >> > >> Response: To enforce new geo-location policies automatically, let's > >> assume that a mobile router (like a mobile BTS in a GSM network) > >> moved from city-x to city-y, and according to city-x regulations VoIP > >> calls over GSM network is allowed, but city-y regulations do not allow > that. > >> Now the topology may reflect same network metrics in both cities but > >> there is no rule that triggers configuration change based on > >> geo-location. > >> > >> > >> --------------------------------- > >> > >> > >> > >> What do you think? > >> > >> > >> Author/Contact Information: > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> > >> Phone: +964 770 533 0306 > >> Email: ammar.alsalih@gmail.com > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > >> ---------------------------------------------------- > >> The ignorance of how to use new knowledge stockpiles exponentially. > >> - Marshall McLuhan > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Bob Hinden
- Re: [Geopriv] Adding GPS location to IPv6 header Shane Amante
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Robin Wilton
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Mark Smith
- Re: [Geopriv] Adding GPS location to IPv6 header tglassey
- Re: [Geopriv] Adding GPS location to IPv6 header Kipp Jones
- Re: [Geopriv] Adding GPS location to IPv6 header SM
- Re: [Geopriv] Adding GPS location to IPv6 header Fred Baker (fred)
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header John Day
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Richard L. Barnes
- Re: [Geopriv] Adding GPS location to IPv6 header Carl Reed
- Re: [Geopriv] Adding GPS location to IPv6 header Richard L. Barnes
- Re: [Geopriv] Adding GPS location to IPv6 header Carl Reed
- Re: [Geopriv] Adding GPS location to IPv6 header John Pickens (jopicken)
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Ivan Shmakov
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header Mark Andrews
- Re: [Geopriv] Adding GPS location to IPv6 header sthaug
- Re: [Geopriv] Adding GPS location to IPv6 header sthaug
- Re: [Geopriv] Adding GPS location to IPv6 header Ammar Salih
- Re: [Geopriv] Adding GPS location to IPv6 header SM
- Re: [Geopriv] Adding GPS location to IPv6 header joel jaeggli
- Re: [Geopriv] Adding GPS location to IPv6 header Ignatios Souvatzis
- Re: [Geopriv] Adding GPS location to IPv6 header Alissa Cooper