backbone transparent proxy / connection hijacking

Has anyone else noticed Digex playing with transparent proxying on their
backbone? We have one of our T1's through them, and found that all web
traffic going out our Digex connection goes through a proxy. We've got
customers with web sites that are broken now because they can't
communicate with things like Cybercash, because their outgoing http
requests are hijacked and sent through a Digex web cache.

Digex wants us to register each web server out on the rest of the
internet that hosts from our network need to talk directly to. This looks
like the beginning of a big PITA.

I wouldn't have a problem with Digex setting up some web caches and
encouraging customers to setup their own caches and have them talk to the
Digex ones via ICP...but caching everything without our knowledge/consent
stinks.

Sigh...... why did I know this kind of crap (hijacking connections) was
going to start. Grrr.....

I understand why people do it, but I do NOT approve of it.

It's a good thing we got our own CIDR block when renumbering out of uunet
space. If Digex doesn't reconsider this new policy, I'll be looking for
quotes on non-proxied transit (T1 or Frame T1) in Gainesville, FL.

Well, I'd love to know where they think they get the authority to do this
from in the first place.... that is, absent active consent.

I'd be looking over contracts and talking to counsel if someone tried this
with transit connections that I was involved in. Hijacking a connection
without knowledge and consent might even run afoul of some kind of tampering
or wiretapping statute (read: big trouble).....

The moving finger of Karl Denninger, having written:

    > Well, I'd love to know where they think they get the authority to do this
    > from in the first place.... that is, absent active consent.

    > I'd be looking over contracts and talking to counsel if someone tried this
    > with transit connections that I was involved in. Hijacking a connection
    > without knowledge and consent might even run afoul of some kind of tampering
    > or wiretapping statute (read: big trouble).....

Hmmm,

Title 18, Chapter 119 - Wire and Electronic Communications Interception...
      Sec 2511

Title 18, Chapter 1030 does not appear to apply.

Standard disclaimers *do*, however apply :slight_smile: See .sig for details.

[...] We've got customers with web sites that are broken now because
they can't communicate with things like Cybercash, because their
outgoing http requests are hijacked and sent through a Digex web cache.

Odd. The box we used to sell through Mirror Image Internet has no problems
reaching Cybercash's site -- though I'll admit that we had a lot of angry
customers for a long time while we found all the wierd little unspecified
protocol violations that "just work" if no "hijacking" takes place.

I don't think Digex is using one of our boxes, and if they are using one
of the "just run Inktomi software on a Solaris box and put an Alteon next
to it" then there are going to be some wierd little unspecified protocol
violations that only Alteon, and a new protocol between Alteon and Inktomi,
could fix. (Our box integrates forwarding and "hijacking" and this is why.)

karl@mcs.net (Karl Denninger) adds:

Sigh...... why did I know this kind of crap (hijacking connections) was
going to start. Grrr.....

I understand why people do it, but I do NOT approve of it.

The box we built was designed for access providers -- you know, put 1,000
modems in a room and sell dialup accounts. It works fine in that context.
And, dialup users are usually not terribly deep as technologists, and they
are used to having their bits mutilated in the great cause of "overcommit."

While a T1 data rate would present no real problem, a T1 customer who would
usually recognize what was happening to them AND care about it, *would*
represent a problem. And besides, a T1 customer would probably be willing
and able to use ICP or at least run their own local cache and point their
browsers at it nontransparently.

Putting these in a POP and hijacking the connections can dramatically lower
the amount of money an NSP needs to spend on long-haul connections (every
locally-fed entry is one you don't pay to transport (again)).

Why do you think this is so popular with the cable modem folks?

However, the first time a customer who didn't know about this gets an aged
quote on a stock (and loses their shirt), or something else happens that
causes real trouble, you've got a major problem, and it might be a legal
rather than an operational one.

I don't consider this kind of thing, done without full disclosure, to be
proper in ANY context. To accomplish the goal you have to *steal* the
packet flow that was given to you and monkey with it.

That act is at least somewhat likely to constitute "wiretapping", and since
its done without the consent or even knowledge of *any* of the parties to
the communication at hand......

The proxy we seem to be trapped with is:
REMOTE_HOST = dca1-wc2.atlas.digex.net
REMOTE_ADDR = 165.117.17.251

Trying 165.117.17.251...
Connected to 165.117.17.251.
Escape character is '^]'.

SunOS 5.6

login:

Darn shame DiGex does not have a NOC. </sarcasm>

randy

We had the same experience with them -- we have a T1 and commercial web
hosting service at safeport.com, and our proxy server on our firewall
became extremely broken due to the web proxy they inserted between us and
the world. Apparently our proxy was generating bad keep-alives in some
form -- of course, none of the web servers we used to contact had a
problem with them. We received a few days warning before they started,
however, so at least we had some idea what might have caused the sudden
breakage of all out-going web access. My personal feeling is that this
might be fine for web-browsing dialup customers, but as a commercial
service buying IP connectivity, we were rather upset.

That's odd, they point you to a proxy in DC?!?

I don't see any ports open besides some standard services. You'd think
there'd be a port for the proxy or something...

-|super-g|-$ strobe !!$
strobe 165.117.17.251
strobe 1.04 (c) 1995-1997 Julian Assange (proff@suburbia.net).
165.117.17.251 22 ssh Secure Shell - RSA encrypted rsh
                     -> SSH-1.5-1.2.22\n
165.117.17.251 25 smtp Simple Mail Transfer [102,JBP]
                     -> 220 dca1-wc2.atlas.digex.net ESMTP Sendmail
8.8.8/8.8.5; Thu, 25 Jun 1998 21:02
                     -> :46 -0400 (EDT)\r\n
165.117.17.251 37 time Time [108,JBP]
                     -> \185=q\182
165.117.17.251 21 ftp File Transfer [Control] [96,JBP]
                     -> 220 dca1-wc2 FTP server (Version wu-2.4(1) Tue Jun
18 14:54:28 EDT 1996) ready.
                     -> \r\n
165.117.17.251 23 telnet Telnet [112,JBP]
                     -> \255\253\24\255\253\31\255\253#\255\253'\255\253$

Charles

~~~~~~~~~ ~~~~~~~~~~~
Charles Sprickman Internet Channel
INCH System Administration Team (212)243-5200
spork@inch.com access@inch.com

Has anyone else noticed Digex playing with transparent proxying on their
backbone? We have one of our T1's through them, and found that all web
traffic going out our Digex connection goes through a proxy. We've got
customers with web sites that are broken now because they can't
communicate with things like Cybercash, because their outgoing http
requests are hijacked and sent through a Digex web cache.

Digex wants us to register each web server out on the rest of the
internet that hosts from our network need to talk directly to. This looks
like the beginning of a big PITA.

Sounds more like time to change Internet vendors. You've now told me whom I
DON'T want to do business with. Yeah, I know renumbering's a bitch. I just
went through it myself.

I wouldn't have a problem with Digex setting up some web caches and
encouraging customers to setup their own caches and have them talk to the
Digex ones via ICP...but caching everything without our knowledge/consent
stinks.

Yeah, it tells you when to change vendors.

The Vixie Interceptor is really the only product on the market that
handles this particualr situation correctly - it is a fine product in that
respect. Paul and his group - worked thorugh that issue with very fine
detail.

To the best of my knowledge Digex is using the Inktomi/Alteon solution.

Odd. The box we used to sell through Mirror Image Internet has no problems
reaching Cybercash's site -- though I'll admit that we had a lot of angry
customers for a long time while we found all the wierd little unspecified
protocol violations that "just work" if no "hijacking" takes place.

I don't think Digex is using one of our boxes, and if they are using one
of the "just run Inktomi software on a Solaris box and put an Alteon next
to it" then there are going to be some wierd little unspecified protocol
violations that only Alteon, and a new protocol between Alteon and Inktomi,
could fix. (Our box integrates forwarding and "hijacking" and this is why.)

<snip>

[...] playing with transparent proxying [...]
[...] We've got customers with web sites that are broken now because they
can't communicate with things like Cybercash [...]

The transparent proxy from one of our firewall vendors wasn't able to
handle connections to Cybercash. Analysis showed that Cybercash was
doing a half-close on their end of the socket, which the proxy took as
a full-close, ending the session.

Perhaps that's a common mistake?

Yet Rich, in the end all our production experience taught that if you
error on the side of correctness even with extensive depth, contrary to
many an assertion, using client side caching has limitations that exceed
many customers expectations for how much bandwidth can be avoided.
Particularly those who see it as relatively cheap.

The good news for the marketing folk is that Inktomi and Cisco are going
to have a much slower uptake on that point.

--david

I wanted to take a moment to respond to this thread which has gotten
somewhat inflamed. 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. In fact, the two posters reporting concrete problems have
both already had them swiftly remedied.

Transparent caching brings with it significant benefits to
the ISPs and backbones who deploy it, but also to the
dialup users, corporate customers and downstream ISPs who
utilize those links. Cached content is delivered accurately
and quickly, improving the experience of web surfing.
Further, caching helps unload congested pipes permitting increased
performance for non-HTTP protocols. Many people believe that
large-scale caching is necessary and inevitable in order to scale
the Internet into the future.

I will spend a few paragraphs talking about each of the concerns
which have been expressed in this thread. Roughly, I think they
are the following: disruption of existing services, correctness
of cached content, and confidentiality/legal issues with
transparent caching. We take all of these issues very seriously
and have had dedicated resources in our development and technical
support groups addressing them for some time.

The center of this debate concerns the rare disruption of
existing services which can occur when transparent caching is
deployed. Two concrete examples of this have been cited on this
list: access to a Cybercash web server and access from an old Netscape
proxy server. Both of these incidents were swiftly and easily
corrected by the existing facilities available in Traffic Server.

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.

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.

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.

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.

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.

The second issue being discussed is the correctness of cached
content. Posters have suggested mass boycotting of caching by
content providers concerned with the freshness of their content.
Most content providers have no such concerns, frankly. The problem
of dealing with cached content is well understood by publishers
since caching has been in heavy use for years. Every web browser
has a cache in it. AOL has been caching the lion's share of
US home web surfers for years. For more information on the ways
in which publishers benefit from caching see our white paper
on the subject of caching dynamic and advertising content:
http://www.inktomi.com/products/traffic/tech/ads.html

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.

Paul Gauthier

" ... and now, a word from our sponsor ..."

Inktomi's Traffic Server customers and other users of transparent

Transparent caching brings with it significant benefits to
the ISPs and backbones who deploy it, but also to the

In this case, it brings a significant benefit to Digex, but hardly the
customers of Digex. Bluntly, it potentially saves digex money when the use
less of their infrestructure to serve the same amount of service to a
client. I didn't say it was wrong, or bad, but lets be clear on who it is
advantageous to.

dialup users, corporate customers and downstream ISPs who
utilize those links. Cached content is delivered accurately

Accurately is a bone of contention. We've all seen what caching can do to
time sensitive web-sites.

performance for non-HTTP protocols. Many people believe that
large-scale caching is necessary and inevitable in order to scale
the Internet into the future.

While it may be many people, they may all be wrong.

of cached content, and confidentiality/legal issues with

I didn'y see any mention of copyright infringement, which will be an issue
at some point. Also, the fact that if I am caching my customers
web-servers, they are potentially getting free service.

These two problems are examples of legacy issues. IP-based
authentication is widely known to be a weak security measure.

But, this is irrelevant if people use it. Thats a simple point.

Most content providers have no such concerns, frankly. The problem

Hah! This is a silly statement. Not to mention, when sites are selling
advertising based upon hits on thier site. Is there a way yet for the
proxy to report back to the cached-site that is served a cached-copy of
it's website?

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.

This part, I agree with you on.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
                  Atheism is a non-prophet organization.
       I route, therefore I am.
       Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member
               Father of the Network and Head Bottle-Washer
     Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834
Don't choose a spineless ISP! We have more backbone! http://www.nac.net
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Accurately is a bone of contention. We've all seen what caching can do to
time sensitive web-sites.

Not really - enlighten us... Web caching when done responsibly by caching
provider, customer AND content server has no "real" dangers of interfering
with dynamic or time sensitive data.

I didn'y see any mention of copyright infringement, which will be an issue
at some point. Also, the fact that if I am caching my customers
web-servers, they are potentially getting free service.

Prefetching is really the only issue that bridges copyright infringement -
all other content was requested by a third party and not the cache itself
- in the arena of prefetching - where the cache is actively making a
decision to gather the content then you may actually have a point for
copyright infringement - but really a minor one.

Hah! This is a silly statement. Not to mention, when sites are selling
advertising based upon hits on thier site. Is there a way yet for the
proxy to report back to the cached-site that is served a cached-copy of
it's website?

You don't need to report back hit stats really - the content provider
merely needs to make "something" non-cacheable with an appropriate http
expires header - it can be something like a 1 pixel gif or maybe the
actual text of the page and take their hits off that - if "your" site
comes up quickly it will reflect better on the dsigner and owner of the
site - caching actually benefits content providers.

Transparent caching brings with it significant benefits to
the ISPs and backbones who deploy it, but also to the
dialup users, corporate customers and downstream ISPs who
utilize those links. Cached content is delivered accurately
and quickly, improving the experience of web surfing.
Further, caching helps unload congested pipes permitting increased
performance for non-HTTP protocols.

Marketing blather. None of the benefits you cite above are due to
transparent caching, not one! They are all the result of caching and can
be had just as well by ISPs who give their customers a choice whether or
not to use a proxy cache.

Many people believe that
large-scale caching is necessary and inevitable in order to scale
the Internet into the future.

These "many people" you talk about are fools who have no understanding of
Internet scaling. There are many uses of the Internet that do not involve
redundant transfers of identical files over the net and those uses are
likely to increase significantly in the future. Internet phone and video
conferencing are a couple of examples but there are many more. Caching is
good to have for a certain limited number of reasons but it will not help
scale the Internet into the future.

are the following: disruption of existing services, correctness
of cached content, and confidentiality/legal issues with
transparent caching. We take all of these issues very seriously
and have had dedicated resources in our development and technical
support groups addressing them for some time.

I take this to mean that Inktomi advises its customers to disrupt their
services by implementing transparent cachin on non-dialup customers?

The center of this debate concerns the rare disruption of
existing services which can occur when transparent caching is
deployed.

It's not a rare disruption, it is a *CONSTANT* disruption of service. When
a customer pays a provider for transit, the provider should not be
intercepting the data streams and substituting another stream that they
*THINK* will be identical. It is an entirely different thing when a
provider either gives a choice to their customer of using a proxy cache,
or notifies the customer that their service is routed through a cache.
This kind of thing is a benefit to the individual dialup customer and they
can always choose to not use the cache or to pay for a different access
service that does not force caching.

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.

The only place that caching has in a backbone network is as an optional
service that backbone customers can hook their own cache into via ICP
if they so choose. Caching is a temporary hack that provides some limited
benefit at the moment but the need for it is fading except in areas that
are a couple of years behind in bandwidth deployment.

For the past 4 years, AS378 has blocked port 80 (all academic network of 8
universities and many colleges) and forced all users thru multiple proxy
servers (most recently Squid). Over the years we had to build up a list
of sites to bypass. But in addition, one has to provide the ability to
bypass based on source IP address (some users just don't want it - even if
it speeds up their page downloads and toasts their bread at the same
time.)

From what I have seen, the Alteon/Inktomi/Netcache/Cisco solutions do

*not* allow for an unlimited bypass list - both based on destination or
source IP address. When that happens, the ISP, Digex in this case, can
have a simple authenticated web page where a customer can add their CIDR
block to a bypass list in the transparent proxy. Till then, all the
bashing will continue.

Add to the things that will break - simplex or asymetrric routing. More
and more customers are ordering simplex satellite lines. Imagine a
European company that buys a 512kb line from an ISP but also buys a T1
simplex satellite line to augment b/w. The http request goes out with the
sat-link CIDR block as source. The request hits the transparent proxy for
a USA based page. The proxy retrieves the page from the USA, using its
expensive transAtlantic link. Page hits the proxy. Now the transparent
proxy needs to deliver the page. But the requestors IP address is located
at some satellite provider in the USA (previously discussed here), so the
transparent proxy routes the page back across the Atlantic for delivery
via the satellite simplex line.

Same problems happen with assymetric routing. I blv Vern has a study that
shows that 60% of all routes on the Internet are assymetric.

Bottom line: w/o bypass based on source or destination, the bashing will
continue.

Hank Nussbacher
Israel