Digex transparent proxying
I went searching through my email (since Digex support claimed customers had been notified of Digex's intent to start transparent proxying) and found that I did get "a message" that I'd missed while out of town for Linux Expo. Here's the message: --- Date: Fri, 29 May 1998 19:37:03 -0400 From: DIGEX Customer Support <support@digex.net> To: DIGEX Customer Support <support@digex.net> Subject: DIGEX Service Enhancement Notification: 06/02/1998 0400 - 0800 EDT Service Enhancement: 06/02/1998 0400-0800 EDT Location: DCA1 POP, Washington, DC During a configuration window between 4am and 8am on 06/02/1998, DIGEX will be upgrading the dca1-cpe router to which your leased line is connected. These upgrades will increase the speed at which you retrieve web pages, as well as improve your web surfing experience. The downtime will be minimal, 15 minutes at the most. We apologize for any inconvenience this scheduled maintenance will cause, and trust the changes to be made will improve your Internet connectivity. Please feel free to contact the DIGEX Customer Service Team with any questions concerning this maintenance, referencing trouble ticket TT-LL0025428. --- That's pretty darn cryptic. "We'll be upgrading the router you connect to...to increase the spead at which you retrieve pages and surf". What does that mean? More memory for the router? A faster CPU module? Why didn't they just come out and say "We'll be reconfiguring the router to which you connect to do policy based routing so we can hijack all your web traffic and run it through a web cache...we'd rather blow our $ on marketing than continue to invest in the infrastructure required to support our leased line sales." Digex is seriously missing the point that not all customers are an office of drones surfing the web all day. We (FDT) use Digex for transit. Several ISPs use FDT for their internet connectivity. By forcing all our traffic through a web cache, they've seriously impacted the service we provide to our customers and the service our customers provide to their customers. Many hours have been wasted at FDT and by FDT's customers debugging problems that I'd originally written off as "user BS" as the description of the problem was just too off the wall to believe. I think we have at least one customer interested in the possibility of legal action against Digex. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
It might also be time for content providers of time-sensitive data on the web to redirect requests coming from Digex' proxy harvest machines to a web page that says something along the lines of "Digex has intercepted your web request and directed it through their web caching system. This impacts the time-sensitive data at this site. Hence you cannot access this site in this manner. Please contact Digex at [insert contact info here] and politely ask Digex to stop intercepting your web requests. When Digex removes this interception mechanism and permits you to connect directly to this site again without any interference or interception, you will again have full access. Please understand we cannot offer full access without a direct, unintercepted connection. Otherwise we cannot maintain the quality and timeliness of the data this web site provides due to interference by a third party." And so forth. Just an idea really. Or does this hijacking mechanism NOT use harvesting techniques that can be detected by the source IP address? Blah. Tis late, I must be babbling incoherently. Aaron out.
On Fri, 26 Jun 1998, Aaron D. Gifford wrote:
It might also be time for content providers of time-sensitive data on the web to redirect requests coming from Digex' proxy harvest machines to a web page that says something along the lines of "Digex has intercepted your web request and directed it through their web caching system. This impacts the time-sensitive data at this site. Hence you cannot access this site in this manner. Please contact Digex at [insert contact info here] and politely ask Digex to stop intercepting your web requests. When Digex removes this interception mechanism and permits you to connect directly to this site again without any interference or interception, you will again have full access. Please understand we cannot offer full access without a direct, unintercepted connection. Otherwise we cannot maintain the quality and timeliness of the data this web site provides due to interference by a third party." And so forth. Just an idea really.
Hay, I like it, but I don't know how many content providers would be willing to do something like this. In fact some contect providers with low bandwidth connections my actually be happy with Digex. I am glad I am not a Digex customer because I would now be looking for a new provider.
Or does this hijacking mechanism NOT use harvesting techniques that can be detected by the source IP address?
Blah. Tis late, I must be babbling incoherently.
Na, I think it is a good idea, I just don't think that many people will put in the effort to make it happen.
<> Nathan Stratton Telecom & ISP Consulting www.robotics.net nathan@robotics.net
Aaron out.
It might also be time for content providers of time-sensitive data on the web to redirect requests coming from Digex' proxy harvest machines to a web page that says something along the lines of "Digex has intercepted your web request and directed it through their web caching system. This impacts the time-sensitive data at this site. Hence you cannot access this site in this manner. Please contact Digex at [insert contact info here] and politely ask Digex to stop intercepting your web requests. When Digex removes this interception mechanism and permits you to connect directly to this site again without any interference or interception, you will again have full access. Please understand we cannot offer full access without a direct, unintercepted connection. Otherwise we cannot maintain the quality and timeliness of the data this web site provides due to interference by a third party." And so forth. Just an idea really.
Or does this hijacking mechanism NOT use harvesting techniques that can be detected by the source IP address?
Blah. Tis late, I must be babbling incoherently.
Aaron out.
For the record, Cisco cache engines honor the 'no-cache' tags. If content providers who deliver time sensitive data use these tags there is no issue. We have been using cache engines here for about a month, and we have only had one minor incident (an authentication issue). Otherwise, they have practically paid for themselfs already. /ajd/ -- _/_/ _/ _/_/_/_/ Andrew J. Doane _/ _/ _/ _/ Director, Network Operations _/_/_/_/ _/ _/_/_/_/ American Information Systems, Inc. _/ _/ _/ _/ Email: adoane@ais.net, http://www.ais.net _/ _/ _/ _/_/_/_/ (312) 255-8500 Voice, (312) 255-8501 Fax For my PGP public key, email me with the subject "pgp request"
participants (4)
-
Aaron D. Gifford -
Andrew J. Doane -
Jon Lewis -
Nathan Stratton