backbone transparent proxy / connection hijacking

Jeremy Porter wrote:

Cisco policy routing can use source IP address for deciding to pass
traffic to the cache engine. The cache engine, normaly can be
configured to exempt destination. I believe that this fixes both

Except that it's an extremely manual process to define these "exemption"
policies on an "it's broken, please fix" basis, and something that will likely

>be duplicated hundreds or thousands of times. Perhaps a more friendly

deployment that allows customers to register for this "big incentive"
individually would make the most sense, rather than just throwing it out there

>and seeing what breaks. With this model it's true that all the benefits of

caching wouldn't be immediately apparent, but the customer will likely be less

>annoyed when something does break, and less inclined to select a new provider.

There is no techincal reason why it has to be a arduous manual process.
Incentives don't seem to work well with existing customers. (And new customers
are happy to manaully configure when you explain that this will on average
improve performance.) Existing customers by and large, do not pay attention
to the email, letters, etc, when sent out. Only when they break, to
they bother to check, and then usually only after calling the 800 number.

While there is little lost in offering the incentive to change
over, it isn't typically going to get the return on investment that
just switching people over will. Of course I can't see any reason
why to not have a autoconfigure exemption, problem reporting page,
and notice, in addition to profiling traffic that can be expected
to break, other than these might seem "hard" as is making the

cache work right, apparently.

Of course, this thread wouldn't have started had caching vendors (or better,
their customers) agreed on what transparent actually means. I seem to recall
one of it's definitions to be "free of deceit. (that's period)", not "free of
deceit .. unless IP-based filtering, or the like (anything else that happens
to break), is deployed". Only one implementation seems to have got it right
at this point, which seems utterly amazing.

Or class of service. I'm sure when can expect the Karl's of the net
to be outraged as soon as people like MCI start offering preimum services
that don't drop packets, because their packets will implictly still be
subject to loss, and it is obviously unethical and unlawful to
implement new methods of delivery of DATA.
For those of us that have been dealing with router vendors and software
vendors on the Internet long enough, it is not at all amazing that
only one vendor does it right. That's one better than usual.

Expecting the customer to be able to have a clue to
go to a www page is a bit much, tho. Some customers have setup
IP based authentication on their NT server, but can't figure out how
to configure SLL which wouldn't be cached, and would be more secure.
The burden of making this work is on the cache operator. Also it turns
out that the sites with the most problems with the cache are the ones
paying the least money for service. Its hard to feel very sorry for
a $20/month dialup customer, who is connecting to his coporate site
with a broken NT server.

I'd think that a $20 dialup customer deserves the same level of service as any

>other customer, else they're obviously in the wrong market. ...and I

certainly wouldn't say that a server, or entire corporation, is in the wrong
for deploying properly working IP based authentication as a first level of

I would be really supprised if you think that a company that is
paying you 10 or 100 times as much deserves the same level
service as a $20/month dialup customer. Remind me not to buy
and DS-3s or T-1s from your company. I don't want my
dollars paying for 24x7 engineer level support for dialup customers.

Customers that pay for a dialup account cannot expect to be
able to run the same applications as customers that
run high speed leased line customer is. There are numerous
BCP and security recommendations that VERY CLEARLY indicate that
IP based authentication is not a sound authentication. If you
are using SSL, you won't be proxied, and won't break. Security
through obscurity is NO security. IP source authentication
is not ANY better than cleartext token based authentication, if anything
its worse as it promotes a false level of security. More importantly
it doesn't even give you that from random assigned dialup IP addresses.