The first thing you should know about EdgeScape is that it is not infallible. The Web, and even IP address allocation itself, is highly dynamic in nature. Ever since Akamai's inception we have been diligently working to map the Internet as accurately as possible such that we are able to deliver cached content closer to end users, pinpoint and avoid areas of congestion and connectivity problems, and deliver even the most highly demanded content in as optimal a way as possible through unparalleled collaboration with Service Providers and Network Partners, and new innovative technologies like Front-End Optimization, Peer-to-Peer content delivery, and collaborative user mapping through EDNS0 for Google and Open DNS implementations.
The EdgeScape database itself is a culmination of weighted source feeds, normal network traffic data collection from network traces and other readily available information, individual corrections/overrides, some hard core Computer Science, and a dab of know-how and artistic application thrown on top. If you ever find a client IP address you know to be sourced from a different location, we encourage you to submit a support request through the Luna Control Center under the EdgeScape product, and reference KB article 4990 ( https://control.akamai.com/core/search/kb_article.search?articleId=4990 ). The change will be evaluated based on impact and other weighted sources, and generally updated within a week or two depending on urgency level. We are exploring other innovative ways to improve accuracy levels such as crowdsourcing which is explored in another blog post here - Can crowdsourcing better map the physicality of the Internet? - The Akamai Blog .
The second thing you should be aware of is that the SLA for EdgeScape is at the country level, where we assure a 99% accuracy. This is very important to understand as it relates to blocking embargoed countries because that 1% or so bias could be in a city or region within a country you are expecting to block. Thus, if you are using Akamai to deliver software that has export controls imposed on it, EdgeScape should not be used as your sole mechanism to achieve that. Akamai makes no warranty of providing comprehensive software export control compliance. A credit auth or other trustworthy user validation that can supply additional end user location data in addition to geo-blocking through EdgeScape is highly recommended.
With that said, Akamai has made a number of improvements to close the gaps and reduce the burden on secondary export controls. In the past we have seen end users skillfully bypassing geo-restrictions and as a result, changed the default way that geo-targeting works by enforcing at the connecting IP. Additionally there is a new EdgeScape2 tag that can be used such that the Edge Server handling the request looks at the full x-forwarded-for chain, connecting IP address, true client IP address, and known proxies used to bypass geo-location restrictions. In the future we may be able to additionally leverage our IP intelligence data such as IP reputation to provide additional layers of protection. Take for instance a set of IPs in China that are known to be attempting brute force attacks on one customer’s security patch database and leveraging it to protect other Enterprise Software Download customers as well. If you attended Akamai Edge 2014, you know that there is a lot of buzz around future API offerings, and this could be an interesting space to invest in further.
Implementing Geo-blocking in this manner does require coordination with your account team and Professional Services engagement and of course EdgeScape subscription which is included in Software Downloads and other flagship products from both Media and Web Experience solution familes. To understand why it is important to use the new EdgeScape tag for this purpose refer to the following table:
As you can see, to provide the optimal (and expected result) when X-Forwarded-For headers are present to block embargoed countries, you should make sure that your geo-blocking uses the new edgescape2 tag. In the next part of this three-part blog, I will discuss some of the peculiarities with reporting on country-level geo-blocking, and how to use the existing Web Services to generate your own standalone reporting interface.