Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any.
This is not data that should be sent on every packet. It becomes redundant.
1- It does not have to be in every IPv6 header, only when there is location update. 2- the host should have the option of not sending location updates. 3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to. ----------------------------------------------------
A good alternative would be to create application layer protocols that could request and send GPS positions.
1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language. 2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible. 3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others .. that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications. [1] https://datatracker.ietf.org/wg/geopriv/charter/ [2] http://tools.ietf.org/html/rfc6442 [3] http://dev.w3.org/geo/api/spec-source.html ---------------------------------------------------------------------------- ------
I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us?
1- The host should have the option of not sending location updates. 2- It's extension header, means it's up to the service provider to use the feature or not. 3- Users are being routed through ISPs, 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). Anythink you write on facebook for example *if you don't use https* can be 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. Other than ISP, sniffers can 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. 4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates. ------------------------------------------- Thank you everyone for your time and professional feedback, I highly appreciate it! Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented. Thanks, Ammar From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome! http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1 Thanks! Ammar Salih
On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih <ammar.salih@auis.edu.iq> wrote:
2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible.
Geographic-based layer 3 routing has been thoroughly discussed on the IRTF RRG and just as thoroughly rejected. It's wholly inadequate as an approximation for topographic locality within the network graph. Uses of geolocation information at layer 3 are similar to uses of the "evil bit." On Sun, Nov 25, 2012 at 1:28 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On 11/24/12, John Adams <jna@retina.net> wrote:
Don't conflate layer 5-7 needs with basic communication requirements. IP is not the place for this sort of header.
IP is the logical place for this kind of header, as this information is node dependent, not application dependent.
As is the user's legal name and social security number. If it isn't processed by the layer 3 protocols, if they don't use it for next hop selection, then it doesn't belong at layer 3.
For example, in the case of an anycasted service, the source IP address does not uniquely identify where the source came from.
Given appropriate construction of the layer 4 protocol, nothing stops an anycasted service from responding with a unicast IP address and using the unicast address during subsequent communication. An anycast service has far better mechanisms available to identify the responding server than stuffing a GPS header in the layer 3 packet. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Sun, Nov 25, 2012 at 12:08:15PM -0500, William Herrin wrote:
On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih <ammar.salih@auis.edu.iq> wrote:
2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible.
Geographic-based layer 3 routing has been thoroughly discussed on the IRTF RRG and just as thoroughly rejected. It's wholly inadequate as an approximation for topographic locality within the network graph.
If relativistic latency component is measurable, that is information useful for mutual time of flight triangulation. WGS84 just gives you a convenient hinge to hang your information on.
Uses of geolocation information at layer 3 are similar to uses of the "evil bit."
You're correct. It's for layer 2 strictly.
On 11/25/12, William Herrin <bill@herrin.us> wrote:
On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih <ammar.salih@auis.edu.iq> wrote: Geographic-based layer 3 routing has been thoroughly discussed on the IRTF RRG and just as thoroughly rejected. It's wholly inadequate as an approximation for topographic locality within the network graph.
Nevertheless, there are some applications in which it might have some merit. If there is even one such application, then it is sensible to have the required bits set aside, so there can be an extension in the limited cases where it is required.
On Sun, Nov 25, 2012 at 1:28 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On 11/24/12, John Adams <jna@retina.net> wrote:
Don't conflate layer 5-7 needs with basic communication requirements. IP IP is the logical place for this kind of header, as this information is node dependent, not application dependent.
As is the user's legal name and social security number. If it isn't processed by the layer 3 protocols, if they don't use it for next hop selection, then it doesn't belong at layer 3.
An extension header at Layer 3 containing this information should be just fine. Or rather, an extension, allowing a reference to a lookup service for that information to be placed in IP headers, for network management should be just fine. The actual underlying plaintext PII best be protected with IPsec and additional measures, but that is the network implementor's responsibility. Not all Layer 3 headers have to influence path selection. There _ARE_ headers for strictly network management purposes. Examples would include the IP TOS header; Route record extensions; Hop limit; Timestamp. The IP TOS header identifies a value, which can be used to prioritize some packets; similarly, a network operator might have a need to prioritize packets with a certain geographical origin at L3, or grant certain throughput and performance characteristics based on source region, to ensure a degree of fairness with their application.
For example, in the case of an anycasted service, the source IP address does not uniquely identify where the source came from.
Given appropriate construction of the layer 4 protocol, nothing stops an anycasted service from responding with a unicast IP address and
They generally will not. The mechanism of operation of an anycasted service is there are a small number of unicast addresses, with routes announced from various different points. If each region had its own unicast IP, it would just be a normal DNS-balanced service. Therefore, the same unicast IP address may be used from multiple regions, for example, the DNS servers in different regions may have identical IP addresses. For network management purposes, on the End user side, it would be useful in some cases, for the IP header of DNS and HTTP response packets, to identify which "node" or site is responding; even if this cannot be indicated in the IP address fields. It may help identify, if an issue accessing an any casted service is related to instability of which route is preferred (E.g. thrashing of the end user's site selection); if there is an extension option available for Recording or Tagging packets with a source ID, a situation, in which the Record Route IP extension is not a viable option.
Bill Herrin -- -JH
Your proposal doesn't even give people a way to encrypt their location data; By moving geodata to a portion of the protocol which is not covered by commonly used encryption methods (i.e. HTTPS, which is up a few layers in the stack) people can't be protected should this data be monitored by a malicious intermediary. Think: Syria, China, Iran, or any other government which will kill you for your words online. Application protocols sending GPS data under say, HTTPS protect the end user from revealing their location to anyone on their path, forcing an intermediary to look up the IP in a common geo database which will be mostly inaccurate in pinpointing users, and hopefully will save lives. Companies like Twitter, Facebook, and some parts of google are going HTTPS by default for this very reason. This proposal is dead, you don't have the sense to lie down.
Et al, There is one simple question that needs to be asked! Ammar Salih @ ammar.salih@auis.edu.iq Are you a terrorist? Ephesians 4:32 & Cheers!!! A password is like a... toothbrush ;^) Choose a good one, change it regularly and don't share it. -----Original Message----- From: John Adams [mailto:jna@retina.net] Sent: Sunday, November 25, 2012 2:20 PM To: Ammar Salih Cc: nanog@nanog.org list Subject: Re: Adding GPS location to IPv6 header Your proposal doesn't even give people a way to encrypt their location data; By moving geodata to a portion of the protocol which is not covered by commonly used encryption methods (i.e. HTTPS, which is up a few layers in the stack) people can't be protected should this data be monitored by a malicious intermediary. Think: Syria, China, Iran, or any other government which will kill you for your words online. Application protocols sending GPS data under say, HTTPS protect the end user from revealing their location to anyone on their path, forcing an intermediary to look up the IP in a common geo database which will be mostly inaccurate in pinpointing users, and hopefully will save lives. Companies like Twitter, Facebook, and some parts of google are going HTTPS by default for this very reason. This proposal is dead, you don't have the sense to lie down.
WHAT??? Is this the extent to which This-List has DEGENERATED??? How dare you make such a horrendous accusation Sir? You may NOT like what OP has proposed. I don't either for more reasons than one! However, YOU are neither qualified NOR authorised to ask such an appallingly INSENSITIVE Question! Your so called "Freedom-of-Speech" DOES NOT translate to Character-Assasination on this or any other forum!! Follow me you ipdog? Find you own bitch to abuse. Don't do it here!! ./Randy --- On Sun, 11/25/12, Network IPdog <network.ipdog@gmail.com> wrote:
From: Network IPdog <network.ipdog@gmail.com> Subject: RE: Adding GPS location to IPv6 header To: "'John Adams'" <jna@retina.net>, "'Ammar Salih'" <ammar.salih@auis.edu.iq> Cc: nanog@nanog.org Date: Sunday, November 25, 2012, 3:16 PM Et al,
There is one simple question that needs to be asked!
Ammar Salih @ ammar.salih@auis.edu.iq Are you a terrorist?
Ephesians 4:32 & Cheers!!!
A password is like a... toothbrush ;^) Choose a good one, change it regularly and don't share it.
-----Original Message----- From: John Adams [mailto:jna@retina.net] Sent: Sunday, November 25, 2012 2:20 PM To: Ammar Salih Cc: nanog@nanog.org list Subject: Re: Adding GPS location to IPv6 header
Your proposal doesn't even give people a way to encrypt their location data; By moving geodata to a portion of the protocol which is not covered by commonly used encryption methods (i.e. HTTPS, which is up a few layers in the stack) people can't be protected should this data be monitored by a malicious intermediary. Think: Syria, China, Iran, or any other government which will kill you for your words online.
Application protocols sending GPS data under say, HTTPS protect the end user from revealing their location to anyone on their path, forcing an intermediary to look up the IP in a common geo database which will be mostly inaccurate in pinpointing users, and hopefully will save lives.
Companies like Twitter, Facebook, and some parts of google are going HTTPS by default for this very reason.
This proposal is dead, you don't have the sense to lie down.
On Sun, Nov 25, 2012 at 02:19:48PM -0800, John Adams wrote:
Your proposal doesn't even give people a way to encrypt their location data; By moving geodata to a portion of the protocol which is not covered
It's not possible to hide location. Anonymity and efficient transport don't mix. This will become even more so at TBit/s transport rates. That's no problem, as you can use e.g. mix networks to provide strong anonymity for those who need at a higher layer. The sooner everbody realizes this, the sooner we can move on.
by commonly used encryption methods (i.e. HTTPS, which is up a few layers in the stack) people can't be protected should this data be monitored by a malicious intermediary. Think: Syria, China, Iran, or any other government which will kill you for your words online.
Application protocols sending GPS data under say, HTTPS protect the end user from revealing their location to anyone on their path, forcing an intermediary to look up the IP in a common geo database which will be mostly inaccurate in pinpointing users, and hopefully will save lives.
Companies like Twitter, Facebook, and some parts of google are going HTTPS by default for this very reason.
This proposal is dead, you don't have the sense to lie down.
While most of the people are trying to save the internet from any form of "goverment" and let it be free, this would be like shooting yourself in the foot. This would be great for troubleshooting things...I agree, but other than that it would create a whole new plethora of privacy concerns. We use the internet to express ideas either through our real life names or through alter-egos that give us anonymity and let us say things we wouldn't dare otherwise. GPS data would just destroy any sort of anonymity that is left on the NET. I can see big companies paying large sums for this sort of info...imagine google, facebook,etc having access to this kind of data. "the host should have the option of not sending location updates." Lets face it...how many people really know what a IP is, what it can do and what you can turn off or on? Other than the IT sector, most other people do not care and they just plug-and-play. This would just create a window through which you could implement such a feature and throw out most security concerns, because the people that actually care understand the feature and can turn it off...the masses are not so lucky and they get the BIG BROTHER treatment. GPS header would have the same effect on IPv6 implementation as CGN. While CGN and GPS data have the potential to make alot of cash for the ISP who implements it...we don't really want that in our lives and it would deter the customers from switching to IPv6 even more. IMHO the Internet should just be free and offer full anonymity, else it would just come crashing down on our heads. On 11/25/2012 2:30 PM, Ammar Salih wrote:
Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any.
This is not data that should be sent on every packet. It becomes redundant.
1- It does not have to be in every IPv6 header, only when there is location update.
2- the host should have the option of not sending location updates.
3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to.
----------------------------------------------------
A good alternative would be to create application layer protocols that could request and send GPS positions.
1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language.
2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible.
3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others ..
that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications.
[1] https://datatracker.ietf.org/wg/geopriv/charter/
[2] http://tools.ietf.org/html/rfc6442
[3] http://dev.w3.org/geo/api/spec-source.html
---------------------------------------------------------------------------- ------
I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us?
1- The host should have the option of not sending location updates.
2- It's extension header, means it's up to the service provider to use the feature or not.
3- Users are being routed through ISPs, 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).
Anythink you write on facebook for example *if you don't use https* can be 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.
Other than ISP, sniffers can 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.
4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates.
-------------------------------------------
Thank you everyone for your time and professional feedback, I highly appreciate it!
Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented.
Thanks,
Ammar
From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header
Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome!
http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1
Thanks!
Ammar Salih
On 11/26/12, Alex <dreamwaverfx@yahoo.com> wrote:
This would be great for troubleshooting things...I agree, but other than that it would create a whole new plethora of privacy concerns.
Just about every new technology, IP itself included has privacy concerns, related to it; which is really just a fancy new name for security confidentiality concerns, regarding WHO is doing what things on the network. That doesn't mean you blacklist those technologies.... In fact, in some cases _identification_ of network nodes is a very good thing. I would like very much for spammers to be identifiable, even at the cost of some so-called "privacy" (not that embedding IP location data helps with that).... Heck, HTTPS has privacy concerns, because it requires a certificate, containing personal details of the server to operate. I suppose it would be rather interesting if the certificate contained GPS details as well, if end hosts' IP stacks were required to verify the GPS data is either accurate or not present, and SSL clients were expected to validate that the details in the IP packets matched, and if a list of GPS positions was declared as a critical X509 extension. Then a third-party hosting provider would not be able to be used to spoof a HTTPS site (without the intruder gaining root access, in order to spoof IP packets). The existence of privacy concerns, does not mean you hesitate to implement a protocol in any way, shape or form. Privacy concerns,mean you as a user of that technology, pull out your handy dandy risk calculator, and weight the details carefully consider, what the probability and impact of the various risks actually are -- what bad things can actually happen, if the detail X is exposed, and what (if any) mitigations you choose for your particular scenario. Which will for end users typically involve setting a local policy such as: o Don't turn on the "Populate Packet headers with Location data" Or: o Don't stamp packets with location data, except to trusted hosts, when stamped packets are sent with headers encrypted over VPN in tunnel mode Or: o Introduce sufficient error, that the GPS data does not significantly compromise location -- -JH
On Sun, 25 Nov 2012, Ammar Salih wrote:
Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any.
This is not data that should be sent on every packet. It becomes redundant.
1- It does not have to be in every IPv6 header, only when there is location update.
It should not be in any IPv6 packet. It has to be in an upper layer protocol.
2- the host should have the option of not sending location updates.
In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol.
3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to.
I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information.
----------------------------------------------------
A good alternative would be to create application layer protocols that could request and send GPS positions.
1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language.
2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible.
3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others ..
that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications.
I prefer application and at most the transport layer protocol extension.
[1] https://datatracker.ietf.org/wg/geopriv/charter/
[2] http://tools.ietf.org/html/rfc6442
[3] http://dev.w3.org/geo/api/spec-source.html
---------------------------------------------------------------------------- ------
I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us?
1- The host should have the option of not sending location updates.
2- It's extension header, means it's up to the service provider to use the feature or not.
3- Users are being routed through ISPs, 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).
Anythink you write on facebook for example *if you don't use https* can be 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.
Other than ISP, sniffers can 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.
4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates.
-------------------------------------------
Thank you everyone for your time and professional feedback, I highly appreciate it!
Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented.
Thanks,
Ammar
From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header
Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome!
http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1
Thanks!
Ammar Salih
Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to switch. In Spanish we have a very strong adjective for this kind of ideas: "pésimo". I couldn't find a similar one in English without using foul words :-) In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors. Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any real useful role for this extension header. cheers! ~Carlos On 11/26/12 9:20 AM, Mohacsi Janos wrote:
On Sun, 25 Nov 2012, Ammar Salih wrote:
Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any.
This is not data that should be sent on every packet. It becomes redundant.
1- It does not have to be in every IPv6 header, only when there is location update.
It should not be in any IPv6 packet. It has to be in an upper layer protocol.
2- the host should have the option of not sending location updates.
In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol.
3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to.
I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information.
----------------------------------------------------
A good alternative would be to create application layer protocols that could request and send GPS positions.
1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language.
2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible.
3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others ..
that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications.
I prefer application and at most the transport layer protocol extension.
[1] https://datatracker.ietf.org/wg/geopriv/charter/
[2] http://tools.ietf.org/html/rfc6442
[3] http://dev.w3.org/geo/api/spec-source.html
----------------------------------------------------------------------------
------
I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us?
1- The host should have the option of not sending location updates.
2- It's extension header, means it's up to the service provider to use the feature or not.
3- Users are being routed through ISPs, 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).
Anythink you write on facebook for example *if you don't use https* can be 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.
Other than ISP, sniffers can 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.
4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates.
-------------------------------------------
Thank you everyone for your time and professional feedback, I highly appreciate it!
Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented.
Thanks,
Ammar
From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header
Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome!
http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t
ext=1
Thanks!
Ammar Salih
On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote:
Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to
I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint). Another such application could be http://en.wikipedia.org/wiki/European_Data_Relay_Satellite (the realtime precision tracking problem has been solved recently).
switch. In Spanish we have a very strong adjective for this kind of ideas: "pésimo". I couldn't find a similar one in English without using foul words :-)
In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors.
Can you see any good uses for this? Area fencing, for games, maybe. I don't see why you couldn't just bind gpsd to port on a public IP, same as GPS sharing over WLAN tethering is done. So it's basically a solved problem, no need for RFC drafts.
Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any
Some routers *are* already on the roofs. Or on towers. Or in LEO. Visibility is pretty good once you're above few 10 km, and weather is just perfect in orbit. The only storms are of the proton particle variety.
real useful role for this extension header.
On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl <eugen@leitl.org> wrote:
On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote:
Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to
I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint).
Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack. Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them. By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location. There are some assumptions in this model which are problematic. Key ones are: 1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access. 2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This behavior is not presently guaranteed. 3. Assumes that the device will originate communication, receiving only replies from the landed end, or will use some intermediary to communicate current geographic information if inbound origination is required. At any rate, I think that discussion of adding a geographic option header to IPv6 should be tied up in the discussion of a routing protocol which critically depends on its presence and can't reasonably be built another way. Otherwise when a needful use case finally comes along, you'll discover that the option's rules of operation don't adequately enable it. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work. On 26 November 2012 17:36, William Herrin <bill@herrin.us> wrote:
On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl <eugen@leitl.org> wrote:
On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote:
Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to
I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint).
Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack.
Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them.
By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location.
There are some assumptions in this model which are problematic. Key ones are:
1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access.
2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This behavior is not presently guaranteed.
3. Assumes that the device will originate communication, receiving only replies from the landed end, or will use some intermediary to communicate current geographic information if inbound origination is required.
At any rate, I think that discussion of adding a geographic option header to IPv6 should be tied up in the discussion of a routing protocol which critically depends on its presence and can't reasonably be built another way. Otherwise when a needful use case finally comes along, you'll discover that the option's rules of operation don't adequately enable it.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Mon, Nov 26, 2012 at 05:46:33PM -0500, Harald Koch wrote:
This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work.
Serval has about 200 m line of sight range. In general LoS visibility e.g. with pole-mounted directional Ubiquity gear is always as the crow flies.
On Mon, Nov 26, 2012 at 5:46 PM, Harald Koch <chk@pobox.com> wrote:
On 26 November 2012 17:36, William Herrin <bill@herrin.us> wrote:
Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them.
By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location.
This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work.
No. It assumes that the /128 route propagates far enough that every router (read: radio tower) operated by the service provider within the rough geographic locality has that route so that wherever the packet lands in the general area, it can make its way to the origin router currently talking to the device. It makes no assumptions about the particular path or paths between those two routers which could be terrestrial radio, satellite, wired or even a VPN across who knows what Internet path. It does set a requirement on the network architecture that at least one such path must exist: network partitions appear deadly to this architecture. I'm not saying this is a good idea. I'm just saying it's a legitimate topic for research and investigation which, if it shows any promise, would support the addition of a geolocation option header to IPv6's layer 3. By contrast, Ammar's other rationale for why to put it there (common interest at layer 7) aren't legitimate reasons for adding data to layer 3. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example. To the extent that you may apply IP ranges to wider geographical areas, and limit the search space to a few % of the total, beyond which devices get a new address pushed as they travel, this is entirely manageable without the new header. Some services dislike the endpoint renumbering like that, and some connections go kerfluey, but most web based activities handle the endpoint getting a new IP just fine; this is what cookies are for. Your SSH connections will remind you that you should be using screen, or not type and drive. But the CHP and road hazards will already do that. Eventually being allowed to use air-to-ground cell data on airliners will be slightly worse, but again, most protocols shrug at this problem. -george On Mon, Nov 26, 2012 at 2:36 PM, William Herrin <bill@herrin.us> wrote:
On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl <eugen@leitl.org> wrote:
On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote:
Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to
I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint).
Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack.
Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them.
By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location.
There are some assumptions in this model which are problematic. Key ones are:
1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access.
2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This behavior is not presently guaranteed.
3. Assumes that the device will originate communication, receiving only replies from the landed end, or will use some intermediary to communicate current geographic information if inbound origination is required.
At any rate, I think that discussion of adding a geographic option header to IPv6 should be tied up in the discussion of a routing protocol which critically depends on its presence and can't reasonably be built another way. Otherwise when a needful use case finally comes along, you'll discover that the option's rules of operation don't adequately enable it.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- -george william herbert george.herbert@gmail.com
On Nov 26, 2012, at 14:51 , George Herbert <george.herbert@gmail.com> wrote:
The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example.
That's true to a limited extent today. It's not likely to remain true. (No, it won't be the driver typing on their smartphone data connection, but it will be the busload or high-speed trainload of people typing, gaming, etc. all the way from SF to LA and/or other non-interactive data usages that are becoming more and more prevalent. Further, the speed of handoffs will have to get faster and the address stability area larger as that starts to include things like airplanes. Owen
On Mon, Nov 26, 2012 at 4:53 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 26, 2012, at 14:51 , George Herbert <george.herbert@gmail.com> wrote:
The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example.
That's true to a limited extent today.
It's not likely to remain true.
(No, it won't be the driver typing on their smartphone data connection, but it will be the busload or high-speed trainload of people typing, gaming, etc. all the way from SF to LA and/or other non-interactive data usages that are becoming more and more prevalent.
Further, the speed of handoffs will have to get faster and the address stability area larger as that starts to include things like airplanes.
Owen
Right, but GPS location in these scenarios is not helpful. Because the network provider has plenty of evidence you're on the move - your cell location starts hopping at significant speeds, it's kind of obvious. You can either handle this with L3/4 stuff - painfully, but one can establish a regional forwarder net which is a downwards-looking default in each region, to handle L3 traffic for nodes that went off the reservation. Or you can handle this at L5 or above, in which case this is not our problem per se; it's the device and consumer services' website or central services site, or P2P type protocols designers problem to handle IP address flips etc. Which, frankly, already is being handled (most mobile users, anyone who uses WiFi in multiple locations + a phone data connection, etc). It's not totally seamless, but it works, and it's good enough. In either case, knowing the GPS location of the phone or device is not relevant to handling the problem or detecting it, beyond what the cell site data gives you naturally. As you already have to support devices hopping IPs, adding network foo (with evident significant downsides) which does not make that hopping IPs problem go away seems like it's a no-answer. -- -george william herbert george.herbert@gmail.com
On Nov 26, 2012, at 06:56 , "Carlos M. Martinez" <carlosm3011@gmail.com> wrote:
Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to switch. In Spanish we have a very strong adjective for this kind of ideas: "pésimo". I couldn't find a similar one in English without using foul words :-)
The rough translation of pésimo is "terrible". And it certainly applies here. FYI. Owen
In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors.
Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any real useful role for this extension header.
cheers!
~Carlos
On 11/26/12 9:20 AM, Mohacsi Janos wrote:
On Sun, 25 Nov 2012, Ammar Salih wrote:
Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any.
This is not data that should be sent on every packet. It becomes redundant.
1- It does not have to be in every IPv6 header, only when there is location update.
It should not be in any IPv6 packet. It has to be in an upper layer protocol.
2- the host should have the option of not sending location updates.
In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol.
3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to.
I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information.
----------------------------------------------------
A good alternative would be to create application layer protocols that could request and send GPS positions.
1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language.
2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible.
3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others ..
that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications.
I prefer application and at most the transport layer protocol extension.
[1] https://datatracker.ietf.org/wg/geopriv/charter/
[2] http://tools.ietf.org/html/rfc6442
[3] http://dev.w3.org/geo/api/spec-source.html
----------------------------------------------------------------------------
------
I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us?
1- The host should have the option of not sending location updates.
2- It's extension header, means it's up to the service provider to use the feature or not.
3- Users are being routed through ISPs, 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).
Anythink you write on facebook for example *if you don't use https* can be 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.
Other than ISP, sniffers can 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.
4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates.
-------------------------------------------
Thank you everyone for your time and professional feedback, I highly appreciate it!
Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented.
Thanks,
Ammar
From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header
Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome!
http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t
ext=1
Thanks!
Ammar Salih
participants (13)
-
Alex -
Ammar Salih -
Carlos M. Martinez -
Eugen Leitl -
George Herbert -
Harald Koch -
Jimmy Hess -
John Adams -
Mohacsi Janos -
Network IPdog -
Owen DeLong -
Randy -
William Herrin