- NANOG - lists.nanog.org

backbone transparent proxy / connection hijacking
by Jon Lewis 29 Jun '98

29 Jun '98

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. ------------------------------------------------------------------ Jon Lewis <jlewis(a)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____

15 17

Re: Digex transparent proxying
by Sean M. Doran 29 Jun '98

29 Jun '98

Patrick Gilmore writes: | Which is why I've asked | them to give me some input. Lots of people here have thought about this a | lot more than I have, perhaps they would care to share their thoughts about | this issue? It's nice that you want to learn, but you have the habit of arguing every little point vigorously more often than asking questions like this one, and frankly, that tends to lead people to be disinclined to try to help you come to your own conclusions, much as was the case with Tim Bass, who behaved similarly. Sean.

2 1

Re: Digex transparent proxying
by Sean M. Doran 29 Jun '98

29 Jun '98

Patrick Gilmore wrote: > I find it repugnant that one of my peers has done so. On an operational note, it seems that Priori has just indicated that it wishes to terminate its peering with Digex. I don't suppose anyone knows which way the packets between those two networks will flow once this principled demonstration of revulsion has been implemented? Sean. (prepared to be told by Randy Bush to contact the DIGEX NOC since Ebone is a customer of Digex's in cooperation with ACONET; not that it matters, since the ASes behind Priori are probably not very crucial)

2 1

Re: Digex transparent proxying
by Sean M. Doran 29 Jun '98

29 Jun '98

Cool, Karl. Then you would be denying your customer access to a market -- a potentially large market -- without telling them. Even only indirectly countable "views" are good for brand managers and marketers, hence the popularity of such things as outdoor advertising. Ironic. Where can they sue? Sean.

8 11

Re: Digex transparent proxying
by Sean M. Doran 28 Jun '98

28 Jun '98

So Karl, you don't like the fact that your customers are maximising distribution of their visual advertising while minimizing their costs (by not paying you for some audience reached through caches), I guess. Brand management people generally only care that a vast number of people associate their brand with some appropriate set of feelings, and that this in turn leads to sales. The cost effectiveness of this approach does not have to be measured directly (by thorough counting or extrapolating from a sample) when other means of testing the effectiveness of a PR/marketing campaign are available. Your analyses of cache effectiveness is also flawed because it is looking at merely the question of ratio of cache hits to misses, and supposing that misses are inherently inefficient. An intercepting proxy which runs a modern TCP stack and which avoids the "herds of mice" problem by aggregating multiple parallel connections into single ones, and which is well-located to avoid frequent fifo tail-drop at the last hop, has a benefit to the ISP that outweighs the cache hit:miss ratio. That is, a cache which imposes decent long-haul TCP behaviour reduces the number of packets which are delivered all the way from the web server to the terminal server but tail-dropped there rather than being delivered to the end user. Where content's effectiveness can be measured by means other than direct counting of "views", _or_ where an intercepting cache reduces the number of retransmissions, or both, this sort of caching is *great* for your customers, because it means they can pay you less, because you ship fewer bits. So I can see why you are so pissed off. Sean. | Oh, I forgot - being stupid and twisting people's words is now considered | a protected class in the United States. - -- Sean Doran Copenhagen, Denmark

4 4

Re: backbone transparent proxy / connection hijacking
by Danny McPherson 28 Jun '98

28 Jun '98

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 > issues. 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. 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. > 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 security. -danny (speaking only for myself)

2 1

Re: backbone transparent proxy / connection hijacking
by Paul Vixie 28 Jun '98

28 Jun '98

Uh, watch out, there are packet flow descriptions here. I'm sorry to post something non-legal-related and non-inflammatory. If there's a better list for technical issues, someone please point me at it :-)... > As far as the asmetric routing issue, the traffic INSIDE the ISP isn't > asmetric, and shouldn't need to be cached. I don't really see the > problem here. (But it could be me.) That's true but only depending on how you look at it. If the client and server are in the same IGP there is probably no benefit to be had from transparent caching -- though replication and optimal redirection would still have a place, at least in the larger IGP's. But if one end of the connection is outside the IGP (and it doesn't matter whether this end is the client or the server), and if the IGP has multiple border gateways, then hot potato routing really screws you since the two connections inside the TCP stream can potentially take different paths. If a stream is going to be intercepted, it must be by a device which sits in the path of both connections, since the sequence numbers of a connection are used in the ACK fields of the other connection. If you can do your interception in your customer's "tail" (the part of the customer's data path where all ingress and egress still uses the same links/routers) you're OK. But if you're sending a customer's segments out one path, which is intercepted by one device, and the ACKs or other inbound segments come in via some other path, which is not intercepted or is intercepted by some different device, then you are pretty much screwed.(*) This is one reason out of several why transparent caching is an access side issue, and why the server side caching has to be done with something more robust like replication and redirection. [ (*) yes I know the two devices can synch their sequence numbers with a back channel, or use predictable ones, but that slope is so slippery that it may as well be paved with vaseline -- let's just not go there, OK? ] -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

1 0

proxying: legal -> com-priv, etc.
by Sean M. Doran 28 Jun '98

28 Jun '98

hi - comments about legal and contractual issues involving transparent proxies belong in com-priv, please. "i will sue them!" "they are breaking the law!" "they are ripping me off!" do not belong here. comments about "intercepting http breaks end2endian internet" belong in end2end-interest, please. comments about "how do i configure this?" and "this broke something, how do i fix it?" belong, respectively, here and at noc(a)digex.net, although a summary of problems and experiences on a technical level might be ok here. this, of course, is totally unrealistic to hope for. maybe someone will invent transparent redirection of email to the right addressees... Sean.

3 2

Favor..
by Derek Elder 27 Jun '98

27 Jun '98

Does anyone have colo space available at any of these locations in NYC: 245 Park Avenue 20 Broad St. 67 Broad St. 55 East 52nd Street I'd need space for a rack and 20 amps of power for 6+ months and I need it ASAP. Any help is much appreciated. Derek Derek Elder US Web / Gray Peak Technologies Network Engineering 212-548-7468 Pager - 888-232-5028 delder(a)graypeak.com http://www.usweb.com A Strategic Partner for the Information Age.

1 0

Re: Digex transparent proxying
by shields＠crosslink.net 27 Jun '98

27 Jun '98

In article <35935600.FF54EBFE(a)infowest.com>, "Aaron D. Gifford" <agifford(a)infowest.com> 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. Any content provider savvy enough to put that up could just as easily put in the proper headers to tag their content as cacheable or uncacheable or cacheable until time X, and that would be better for *everyone* involved. -- Shields, CrossLink.

6 11