The Cybercash server performed client authentication based on
the IP address of the TCP connection. Placing a proxy (transparent
or otherwise) in between clients and that server will break
that authentication model. The fix was to simply configure Traffic
Server to pass Cybercash traffic onwards without any attempt to
proxy or cache the content.
But, as you point out, this basically requires that each server using
this authentication model be identified, then corrected on the cache
server on a case-by-case basis. While such servers are, at this point,
a rare occurence, it does happen, and developers should be free to use
this technology if it meets their needs without fear of having their
clients suddenly disconnected from them by their client's ISP.
The second example was of a broken keepalive implementation in
an extremely early Netscape proxy cache. The Netscape proxy
falsely propagated some proxy-keepalive protocol pieces, even
though it was not able to support it. The fix was to configure
Traffic Server to not support keepalive connections from that
client. Afterwards, there were no further problems.
Although this proxy is broken, and the owners should upgrade,
there is still the issue of choice.
These two problems are examples of legacy issues. IP-based
authentication is widely known to be a weak security measure.
The Netscape server in question was years old. As time goes
on, there will be a diminishing list of such anomalies to deal
with. Inktomi works closely with all of our customers to
diagnose any reported anomaly and configure the solution.
Weak or not, it is in use. As such, it is not appropriate for
an ISP to inflict this technology on all of their customers
without consent from the customers.
Beyond that, to scale this solution, Inktomi serves as a
clearinghouse of these anomaly lists for all of our customers.
A report from any one customer is validated and made available
to other Traffic Server installations to preempt any
further occurrences.
While this is a good positive customer service step, it is not
by any means a complete resolution to the problem. It still
requires a (potentially) good deal of overhead to keep the list
of anomolies up to date on the server. Further, the cache server
inherently degrades performance to these sites.
Inktomi also conducts proactive audits both inside live Traffic
Servers and via the extensive "web crawling" we perform as part
of our search engine business. The anomalies discovered by these
mechanisms are similarly made available to our customers.
This is a much better and likely more thorough way to gather a list
of anomolies. However, given that, I'm surprised you didn't catch
the CyberCash issue prior to it becoming one.
And finally, there has been confusion concerning the
confidentiality and legal issues of transparent caching.
Transparent caching does not present any new threat to the
confidentiality of data or usage patterns. All of these issues
are already present in abundance in the absence of caching.
Individuals responsible for managing networks will have to weigh
the advantages of caching against these more nebulous
considerations. We, and many others looking towards the future
of a scalable Internet, are confident that caching is becoming an
integral part of the infrastructure, and provides many benefits to
hosters, ISPs, backbones and surfers alike.
Maybe, but it's use should be voluntary on the part of both sides.
Otherwise, the cache implementors (not Inktomi, but the ISPs who
implement transparent caching for all their customers) are
providing a service different from that expected by the bulk of
their customers when they sign up.
Paul Gauthier
Owen DeLong
Opinions expressed are mine and mine alone, and do not reflect the
views of my employer, were not cleared by my employer and were
submitted to the net from a machine not owned or operated by my
employer.