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 leve=
l of technical detail to help people understand.  I would want to see at le=
ast:
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 to=
ols 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 netwo=
rk, only possibly the privacy of users.  In specifying the privacy mechanis=
ms in your detailed description, I would suggest that you make this mechani=
sm "opt-in" by end hosts.  For example, you could have an all-zero geolocat=
ion 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 optio=
n is already present (indicating consent).

It would also be helpful to clarify how this option would relate to other s=
imilar 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 <[email protected]> wrote:

> Hello Fred,
> =

>  =

> You may certainly file an internet draft with your ideas. You will want t=
o 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 specificatio=
n, and you will need to build that consensus. You will want to make your ca=
se, 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/w=
g/geopriv/charter/. =

>  =

> Appreciate it, the first draft has been submitted already  http://datatra=
cker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_text=3D1  =

> =

>  =

> 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 eve=
r a case in which your GPS location is needed by the application but may ne=
ed to be guarded for privacy reasons, you will want to put it in the applic=
ation 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 cou=
ld find them included in the internet draft above.
> =

>  =

> I would expect that 6man might tell you that the IPv6 header has one prim=
ary 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 pr=
obably in the wrong header.
>  =

> I agree, also from OSI perspective, I would think twice before including =
location field into network layer, then again, it=92s the only layer that m=
akes the field useable to routers.
> =

>  =

> =

> Thanks,
> =

> Ammar
> =

>  =

>  =

> From: Fred Baker (fred) [mailto:[email protected]] =

> Sent: Friday, November 16, 2012 6:05 AM
> To: Ammar Salih
> Cc: <[email protected]>; <[email protected]>
> Subject: Re: Adding GPS location to IPv6 header
>  =

> You may certainly file an internet draft with your ideas. You will want t=
o 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 specificatio=
n, and you will need to build that consensus. You will want to make your ca=
se, 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/w=
g/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 eve=
r a case in which your GPS location is needed by the application but may ne=
ed to be guarded for privacy reasons, you will want to put it in the applic=
ation 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 head=
er 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 achiev=
e 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=
=92ve written the below document to summarize few ideas.
> =

> Is it possible to publish this on IETF website? even if it will not be im=
plemented 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:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>  =

>    This document describes IP-LOC, an extension to IPv6 header which sugg=
ests adding GPS coordinates, as the current method of determining the locat=
ion 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 r=
outer 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 w=
hen mobile routers move from one geo-location to another which has differen=
t policy.
>  =

>  =

>  =

>  =

>  =

> Benefits of adding GPS location to IPv6 header (IP-LOC)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>  =

>  =

> 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 restaura=
nts in the city), another good example would be webpage=92s language, my la=
nguage will be detected more accurately based on my area rather than my cou=
ntry, as there are many countries with more than one popular language, not =
mentioning that many ip registrations does not even reflect the traffic ori=
ginating 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 regis=
tered this IP subnet, IP-LOC suggests making locations more accurate and co=
ntrollable through OS and network devices, exactly like IP addresses (user =
can change his/her IP address, but router can also modify the header inform=
ation - in case it's required).
> =

> -------------------------------
>  =

> =

> Routing: Policy based routing, based on geo-location, like routing predef=
ined traffic through certain server or path, for different purposes (securi=
ty, manageability, serviceability like choosing language, or routing traffi=
c to specific cashing or proxy server based on country .. etc)
> =

> -------------------------------
>  =

> =

> Copyright law: It happens when certain media/web content is not allowed i=
n 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 t=
his case (if it=92s required in future) the ISP can tag traffic with countr=
y/city more accurately as traffic passes through ISP=92s boarder routers.
> =

> -------------------------------
>  =

> Maps, navigation, emergency calls and many other services will be also en=
hanced with accurate locations.
>  =

>  =

>  =

>  =

> =

> CURRENT ARGUMENTS AGAINST THIS IDEA:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =

> =93Adding GPS position to every IPv6 header would add a lot of overhead=
=94
>  =

> 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 locat=
ion updates.
>  =

> -------------------------------
>  =

> =93What about privacy?=94
>  =

> Response: User should have the option of not sending location updates. Us=
er 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=92s router-to-router link, then no need to be worried about privacy=
 as such information usually configured on a separate network.
>  =

> --------------------------------
>  =

> =93a good alternative would be to create application layer protocols that=
 could request and send GPS positions=94
>  =

> Response: the layer-7 location request will not be detected by layer-3 de=
vices (Routers), I am assuming that in the future, GPS capability will be a=
dded to the router itself (just like smart phones), features like packet ma=
rking and classification based on geo-location will be required to enforce =
the new geo-location policies.
>  =

> --------------------------------
>  =

> =93For location-based routing protocols: Why would you want this?  Geogra=
phical location isn't actually that important a metric for routing; what yo=
u care about there is *topological* location, how far I am away from you in=
 terms of hops or latency=94
>  =

> 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 r=
outing, like, routing traffic coming from French speaking users (in multi-l=
anguage country like Canada) to google.fr
>  =

> ---------------------------------
>  =

> =93For geolocation-based ACLs: you have the problem that if the geolocati=
on is attached by the endpoint, then it can't be trusted, since the endpoin=
t would lie to get past the ACL.  If it's attached by a router, the ACL nee=
ds to have proof that the router attached it (and not the endpoint), which =
means that you would need a signed geolocation header=94
>  =

> Response: You could have the router modify the location field anyways, ju=
st like L3 QoS fields, if you don't trust the host, so no need for encrypti=
on or security, additionally,  ACL is not only for security, it could be us=
ed for routing, QoS ..etc, so the host will not always has the motivation t=
o manipulate the location field.
>  =

> ---------------------------------
>  =

> =93Why can=92t you simply implement rules related to geo-locations static=
ally on the network device (router, firewall .. etc)?=94
>  =

> Response: To enforce new geo-location policies automatically, let=92s ass=
ume that a mobile router (like a mobile BTS in a GSM network) moved from ci=
ty-x to city-y, and according to city-x regulations VoIP calls over GSM net=
work 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: [email protected]
>  =

> =

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>  =

> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles exponentially. =

>    - Marshall McLuhan
>  =

> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/geopriv

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------