Re: [Geopriv] Adding GPS location to IPv6 header

[Mark Andrews <[e-mail]>]

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]