RE: [Geopriv] Adding GPS location to IPv6 header

["Ammar Salih" <[e-mail]>]

Mark,

> There are LOTS of ISPs between the client and the destination.  Most of 
> these can get nothing about your location.

They can get much more! trust me, the point is that if you don't trust the
ISP then you should be worried about all your un-encrypted traffic, not only
location. 

Anythink you write on facebook for example *if you don't use https* can be
easily detected, including location tags,relationships,activities,  wall
posts, friends ... and much more, all your http traffic, including documents
you read, messages, usernames, passwords, bank accounts ...etc.

One last point, is that your current IP address reflects your location, I
can simply do ip lookup and find out your location. Would that be also
considered as privacy breach?
 

Thanks,
Ammar


-----Original Message-----
From: Mark Andrews [mailto:[e-mail]] 
Sent: Wednesday, November 21, 2012 10:05 AM
To: Ammar Salih
Cc: 'John Pickens (jopicken)'; [e-mail]; [e-mail]; 'Fred Baker
(fred)'
Subject: Re: [Geopriv] Adding GPS location to IPv6 header


In message <[e-mail]>, "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:[e-mail]]
> Sent: Tuesday, November 20, 2012 11:48 PM
> To: Carl Reed; Richard L. Barnes
> Cc: [e-mail]; [e-mail]; 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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Carl Reed
> Sent: Tuesday, November 20, 2012 12:15 PM
> To: Richard L. Barnes
> Cc: [e-mail]; [e-mail]; 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 ; [e-mail] ; [e-mail] ; '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" <[e-mail]> 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: [e-mail] ; [e-mail] ; '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 <[e-mail]>
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:[e-mail]]
> >> Sent: Friday, November 16, 2012 6:05 AM
> >> To: Ammar Salih
> >> Cc: <[e-mail]>; <[e-mail]>
> >> 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: [phone]
> >>   Email: [e-mail]
> >>
> >>
> >> -------------------------------------------------------------------
> >> - IETF IPv6 working group mailing list [e-mail] Administrative 
> >> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> -------------------------------------------------------------------
> >> -
> >>
> >> ----------------------------------------------------
> >> The ignorance of how to use new knowledge stockpiles exponentially.
> >>   - Marshall McLuhan
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]