Dude, where's my IP?

I love to check in on social networks like Foursquare and Google+. Most of the time, there's no point to it, but it's fun to see what friends and colleagues are up to or discover new local haunts. Despite the fun and games, location is much more important to the network than it appears. My physical location may have little or everything to do with my network location and there's no reason for them to match exactly, but there are significant reasons to be more accurate.

An experienced routing and switching engineer knows that the physical mappings do not always match their logical mappings. If someone hands me a layer 3 topology diagram, I cannot assume that the physical connections will match. MPLS is a great example of this where my layer 3 neighbor may be multiple hops away and yet appears locally via CDP (Cisco Discovery Protocol) or LLDP (Link Layer Discovery Protocol ). Emerging technologies like LISP (see previous articles on Locator/Identifier Separation Protocol) allow for increased IP address mobility and will likely further complicate the issue.

Check, Check!

Mobile check in applications are pretty smart about knowing where I am because most of my devices have a GPS chip or have the ability to receive location information from a 3G/4G tower. If I'm inside a building, however, the GPS receiver cannot hear the satellite signal and the location function must fall back to the last known position. Or if I am on WiFi, it will attempt to use a service to map the public address of the WiFi network to a physical location.

These services try to learn the location based on search data, user contributed data, and service provider information. If I and others consistently check in at a location such as the Cisco Fort Lauderdale office ( where I'm currently the 4sq mayor ), the IP geolocation service can make an educated guess as to the location.

Unfortunately, many of these services do little follow up checking and it's up to the application to sanity check the information it receives. Here's a mildly interesting anecdote to illustrate:

Once Upon a Time at Cisco Live!

At Cisco Live! 2013, I checked in and tweeted from outside the convention center. I had a clear view of the satellites and "Hey, look at me, I'm at Cisco Live! in Orlando" was shared. I got my badge and began to roam inside and decided to join the Cisco WiFi along with 13,000 other people. Quickly I saw something I wanted to share on a social network and while composing a tweet on my smartphone, I noticed it said I was in San Jose, California. Huh?

This amused me, because I realized what had happened; the public address I piggybacked from Cisco was an address registered in San Jose. Since I'm a smart alec, I decided to check in on Foursquare and pick up some extra travel points. Denied! Foursquare knew I had recently checked in thousands of miles away and I could not possibly have traveled that far. I received a 'nice try' type message. Darn.

Not every network did these sanity checks and even then it was only done at the top application layer. This is an important component that is being overlooked in the IDS / Threat Defense scoring and possibly the BYOD onboarding process as well as a security consideration.

Faking Waldo

The GPS chip location can be faked if the device is rooted/jailbroken and it is possible the user may be further away via a VPN connection, but a simple measurement of an icmp ping round trip time can yield a lot of information. If the ping, GPS coordinates, and IP lookup do not quite add up, this can be factored into the security score and tied to trends for the IP, the user, or both.

The most extreme example I can provide is a lookup of the IP for my personal website which is collocated on a /19 block allocated to a satellite service provider Vitacom. Because their IP address block is allocated as 'satellite', some of the geolocation service providers mark my IP as being in the middle of the Atlantic Ocean or in Africa.

When I challenged their results, the geolocation provider was unperturbed. Since it was an IP that had mobility, for security reasons they returned those positions. I get that, we've all had the Nigerian prince email or fax. If you ping it from the USA, however, it's easy to see that 30-110ms could not possibly be via a satellite link unless I was able to increase the speed of light. A satellite link would typically be 500ms or more.

Doing it right is still wrong?

Granted it could be a proxy and while this is a corner case today, LISP could make geolocation static location databases useless. Even Google gets it wrong. If you look at your security settings, you can see where you logged in from and it will list the IP. My AT&T Uverse IPv6 address shows as Chicago, IL (check your Google location history) and my IPv4 logins are from Florida. Google is doing the right thing and failing my login periodically as I 'jump' between Florida and Chicago, but it's annoying to have to keep logging back in until this gets caught up.

We can take a page from Google or Foursquare and start looking at location data as part of the multi-factor user authentication and exchange this with data from the WiFi access point to start creating a more secure network between the physical and the application layers. We know the value of being in the right place, at the right time. Let's validate that. What are your ideas to improve this?