When a major Internet backbone provider installed a new technology designed to speed up its network, some unintended side effects caused an e-commerce snafu that has called the technique into question among some experts.
The incident exposed unforeseen perils of caching, a technology that promises faster delivery of Web content and reduced network traffic load on Internet Service Providers (ISPs) and corporate networks.
"It resulted in a number of our customers getting double-charged and others not getting charged to their credit cards properly," said Dr. Irvin Gleim, owner of Gleim Publications, which uses the CyberCash system to sell training publications from its Web site.
"[Our site] was affected to such a degree that for a short period of time we had to shut down our secure server and not take any more transactions," Gleim said.
The problem essentially came down to a case of mistaken identity. It began when Digex, a national backbone network service provider that fed traffic to Florida Digital Turnpike, Gleim's ISP, introduced a caching system from Inktomi (INKT).
Caches copy popular Web content onto servers or other machines residing on networks closer to the end user. The technique is used to check a Web page's "freshness," so that if sites in the cache are getting old, a new page is requested from the originating Web site.
The cache allows an ISP to deliver clones of Web pages from the cache rather than fetching the faraway original page, a process that can save delivery time and cut down on network load.
But when Digex installed Traffic Server, an Inktomi caching software product, a critical connection began to fail between Gleim's Web site and the CyberCash payment system that he uses to process transactions.
Each transaction made at Gleim's site involves an interaction between the site's Web server and a CyberCash server. Normally, the CyberCash server would recognize Gleim's server by its IP address, and therefore "trust" that the connection -- and thus the transaction -- was legitimate.
When the CyberCash server saw requests coming from a cache, which has a different Internet address than the Gleim Publications server, it didn't recognize the originating server and rejected the payment requests.
Gleim Publications, understanding that the problem took place as a result of Digex's networks, says it is considering legal action against the service provider for damages.
"Because of transparent caching, it was coming from the wrong IP address," said Florida Digital Turnpike network administrator Jon Lewis.
When asked for the details of the problem experienced by Florida Digital Turnpike and its customers, Pritchard said Digex would not be likely to comment on a relationship with a specific customer.
Digex spokesperson Ben Pritchard said customers were notified by email that the Traffic Server service would be installed.
"Most of them, once they've seen the benefit from [the Traffic Server], don't want to exclude themselves from it," said Franklyn Howell, the company's senior manager of technical support.
Howell did acknowledge that some of its customers using its cached router had particular issues "where IP-based authentication was going on."
She added that in those specific cases, Digex "would take a look" at circumventing the cache for some customer traffic.
Lewis said he wasn't pleased with Digex's initial response when he called the company's attention to the problem.
"The original response I got from them last week was, 'This is the way it was, and that's life,' and I didn't react too well to that." After indicating his ISP would be looking elsewhere for network access, however, he said Digex showed a willingness to try to address the problem.
Florida Digital Turnpike's Lewis said the only email he received from Digex prior to that company installing the cache did not address the cache specifically. It only notified customer networks of anticipated downtime as Digex performed a router upgrade that would speed the delivery of Web pages, he said.
Digex's Howell said an email further clarifying the caching issue is due to go out on Tuesday.
"We probably would have asked them to do this for just our dialup IP address ranges if anything at all," Lewis said, if he'd received more specific information. Generally, Lewis said he would like more control over what is and isn't cached.
Lewis said Digex's proposal currently involves his ISP keeping track of which destination IP addresses should not be "proxied" through the cache. But he was not enamored of the idea that this would require registering each IP address with the service.
Paul Gauthier, Chief Technology Officer for Inktomi, developer of the caching technology in use at Digex, posted a note to the network administrator's mailing list in response to concerns.
"The problems being highlighted are not new or unknown and there are standard remedies in use by Inktomi's Traffic Server customers and other users of transparent caching," he wrote.
Inkomi provides the search technology underlying Wired Ventures' HotBot search engine.
Gauthier said the disruption of existing services, correctness of cached content, and confidentiality/legal issues with transparent caching are all addressed by Inktomi's development and technical support group.
Disruption of service problems are possible but rare, Gauthier said. He added that the workaround -- passing CyberCash traffic onward without any attempt to proxy or cache the content -- was easily implemented.
Issues of confidentiality and disclosure should be resolved between ISPs and network administrators deploying the technology, Gauthier said.
