Subject: Re: [Geopriv] IPv6 modification suggestion

From: "Ammar Salih" <[email-masked]>
Date: Thu, 18 Oct 2012 23:03:32 +0300

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:[email-masked]] 
Sent: Thursday, October 11, 2012 11:41 AM
To: 'Bob Hinden'
Cc: [email-masked]'
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:[email-masked]]
Sent: Thursday, October 11, 2012 6:37 AM
To: Ammar Salih
Cc: Bob Hinden; [email-masked]
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: [email-masked]
> The American University of Iraq - Sulaimani
>  
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Oct 2012 08:46:03 -0400

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:

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

---

From: "Ammar Salih" <[email-masked]>
Date: Mon, 22 Oct 2012 01:33:21 +0300

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:[email-masked]] 
Sent: Friday, October 19, 2012 3:46 PM
To: Ammar Salih
Cc: [email-masked]
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

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!
> 
> 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
> 
> 
> 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)
> 
> 
> 
> This can be set manually in case of any privacy concerns, just like 
> other header's information like IP address.
> 
> 
> 
> 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.
> 
> 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.
> 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.
> 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.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2012 09:12:03 -0400

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>

---

From: "Ammar Salih" <[email-masked]>
Date: Mon, 22 Oct 2012 21:05:32 +0300

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:[email-masked]] 
Sent: Monday, October 22, 2012 4:12 PM
To: Ammar Salih
Cc: [email-masked]
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

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.
> integrated into one header, as GPS devices becoming smaller and 
> accurate cooedinates are higly required.
> 
> Thanks,
> Ammar
> 
> 
> 
> 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.
> 
> 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
> 
> 
> [3] 
> <http://tools.ietf.org/html/draft-thomson-geopriv-http-geolocation-00>
> 
> 
>> 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.
>> 
>> 
>> 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 
>> 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
>> restaurants available in my neighborhood instead of all restaurants 
>> in the city), another good example would be webpage's language, my 
>>> Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead 
>>> - Voice and Data Support Services
>>> 
>>> IETF IPv6 working group mailing list [email-masked] Administrative 
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6