- NANOG - lists.nanog.org

info
by Stew L. Piggien 30 Jun '98

30 Jun '98

In case anyone needs it, here's rolex's real info: Name Raymond Torricelli Address 926 Webster Ave New Rochelle, NY 10804-3533 Phone num (914) 235-5245 Alt: (914) 576-7859 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

RE: backbone transparent proxy / connection hijacking
by Pete Farmer 30 Jun '98

30 Jun '98

On Monday, June 29, 1998 John Fraizer [mailto:John.Fraizer@EnterZone.Net] wrote: >Backbone providers are here to provide unhindered >connection to the internet for their clients. Is that necessarily what the customer is after, or is that a polemic? <customer_view> I think my backbone provider is there to provide me with access to Internet content, delivering the mix of throughput, latency, and price that's right for me. And I can see where caching *might* allow a service provider to better meet my needs. </customer_view> >Hijacking your clients, their clients, etc connections >and shoving them through a proxy cache to save money is >unethical. > >Transparent proxys have one place. On the CLIENT side of the connection. As a customer, I don't give a hoot for belief systems and opinions on where things 'ought' to be. Don't talk to me about 'unethical,' talk to me about better ways to solve my business problem. Pete ______________________________________________________________________ Peter J. Farmer E-mail: pfarmer(a)strategies-u.com Strategies Unlimited Voice: +1 650 941 3438 201 San Antonio Circle, Suite 205 Fax: +1 650 941 5120 Mountain View, CA 94040 WWW: http://www.strategies-u.com

1 0

Re: backbone transparent proxy / connection hijacking
by John Fraizer 29 Jun '98

29 Jun '98

At 04:31 PM 6/26/98 -0700, you wrote: >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. Horse-hockey. Purchasing the proper amount of bandwidth from your upstream and your upstream implementing the facilities to deliver that bandwidth is what is necessary to scale the internet into the future. Over-allocation is bad enough on the dialup-ISP side of the equation without backbone providers doing the same thing. If your backbone provider doesn't have the capacity to deliver what they have sole to you, it's time to contact two entities: Your lawyer and another backbone provider. >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. With web commerce companies popping up all over, who wants to be the one to track these companies and their netblocks and reconfigure the proxy every time one comes online or changes providers? This would be a nightmare for the dialup provider, let alone their provider or their providers provider. If we purchase transit from provider X because provider Y doesn't peer with provider Z from whom Commerce Provider Alpha gets their connection, who do I yell at when my customers yell at me? Sounds like a huge finger-pointing match to me. Like we don't already encounter too many of those? > >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. See above. Backbone providers are here to provide unhindered connection to the internet for their clients. If someone wants to set up a proxy, it's their business. Publish the address of the proxy and have at it. Hijacking your clients, their clients, etc connections and shoving them through a proxy cache to save money is unethical. Transparent proxys have one place. On the CLIENT side of the connection. >These two problems are examples of legacy issues. IP-based >authentication is widely known to be a weak security measure. IP based authentication, alone, may be somewhat weaker than we would like. It is however much more secure than having one central point on Backbone Z that all web based traffic goes through. IP based authentication is also very nice augmentation for challenge/response and even simple username/password schemes. It limits the usefulness of authentication tokens that fall into the hands of those who do not possess the skill-sets necessary to do blind attacks. >The Netscape server in question was years old. As time goes >on, there will be a diminishing list of such anomalies to deal >with. This is like saying, "Internal combustion automobiles are outmoded with the advent of plentiful gerbils to power the vehicle on treadmills." Haven't we all learned the backward compatibility lesson? >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 And we all know that AOL is the #1 choice of the uninitiated, a proving ground until they graduate to a SERVICE PROVIDER vs. a Content Provider. >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 "Dynamic content heuristics In the event a publisher has not incorporated cache-control headers into their site, Traffic Server uses a number of heuristics to recognize dynamic Web pages (for example, pages generated using cgi-bin or form submissions). These pages are automatically refreshed on every access." So, If someone is using site exec, etc in their code, and their provider/webmaster/mother didn't set up Progma: nocache, they're effectively screwed...erm...cached, right? "Refresh algorithms For pages not utilizing cache-control headers, Traffic Server ships with a default refresh cycle of one hour for all pages. In addition, the cache uses sophisticated algorithms to selectively update rapidly changing pages at a faster rate. These updates are accomplished using an "If-Modified-Since" request, which saves bandwidth if the page has not changed. " Fantastic. So, lets say I'm Joe Banner Advertizer. Company X has paid me present their banner. They wanted to limit the amount of money they spent so, they had me code my servers to only display their banner X times per day since I bill them on impressions. Backbone provider Z installs one of your boxes. By default, no matter how many connections on the limited....erm...client side of the box are initiated to retrieve a "fresh" banner from our banner-farm, you send them Company X until the cache times out. "Users see improved performance because static graphics and applets are delivered from nearby caches, insulating them from congestion in the Internet cloud." Let me rebut this quote with yet another quote from you: "Every web browser has a cache in it." I'll bet on the speed of the slowest LOCAL cache against one at the provider any day. >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. Oh really? Lets say that I'm Joe Internet Terrorist. (Hey, they thought that the mailman was harmless too!) I work at backbone provider Z. I want to create panic on a global scale. I insert a machine on the business end of your proxy/cache that claims to be some corporate giant who has 80% share of the desktop market. Now, any requests that your cache makes are served up by my "local" box and not the REAL webserver. Just to make things interesting, I tell the webserver to serve up ONE page no matter what the request is for. On that page, we put something to the effect of "We have declared bankruptcy. We will no longer support any product we have sold you. You're screwed." You're saying "It would be just as easy and probably more likely that someone would put that box at Company X instead of at the proxy/cache." Not if they also wanted to spoof the webservers of the FBI, CIA, etc. Now, we have the entire internet community served by carrier Z convinced that they're screwed. "I couldn't resist Your Honor. It was just too easy. It was better than broadcasting an alien invasion on the radio!" ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

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

29 Jun '98

Patrick Gilmore writes: | As for the average NANOG reader, I would have to agree with you that they | are capable of thinking for themselves. Yes, and I am sure they fully realize that the loudest noises have been made by DIGEX's *competitors* complaining about DIGEX's customer-notification or service change, and consume a large block of salt. Sean.

2 1

Re: Filtering Unregistered Blocks (WAS: small vent)
by dlr＠bungi.com 29 Jun '98

29 Jun '98

[In the message entitled "Filtering Unregistered Blocks (WAS: small vent)" on Jun 29, 11:46, "Patrick W. Gilmore" writes:] > At 12:45 PM 6/28/98 PDT, Dave Rand wrote: > > >This has, in fact, happened before. One of the reasons that the unallocated > >spaces are listed on the RBL. > > This topic comes up every now and then. I've searched the ARIN site and > found some very outdated lists (some as old as 1996, but none newer than > Feb, 1998). I've searched the archives, but no one seems to have an answer > - except you. How do you tell what is and what is not allocated? Unallocated is (once again) a state of mind. By unallocated, the RBL looks upon the IANA allocation of space, not the ARIN view. So, for example, 2.0.0.0/8 is on the RBL (as is 0.0.0.0/8). We watch for IANA allocation of new blocks, and when they are allocated, remove them from the RBL. Of course, this takes more work, and requires that we watch closely. As an example, AS3259 is currently advertising a bogon. *>i213.102.1.0 207.240.113.165 10 100 0 3847 3259 3259 i > > Perhaps you could export just the non-assigned blocks in the RBL? Maybe > under a second AS or something? I have no problem with the RBL myself, but > some of my customers want a "full table", and won't take an RBL filtered > one. That's not how the RBL works in BGP mode. You can (easily) accept a feed from the RBL, and filter to accept only /8's from the RBL, which will give you the desired information. You are not permitted to redistribute AS7777 routes to your customers (or anyone, for that matter) without express approval and a disclaimer in place, so AS7777 is typically marked as a "no-export" community. The RBL, in BGP mode, is used by route-mapping the addresses listed on the RBL to a specific address. You can, for example, route all traffic to RBL listed hosts to go through a 9600 bps dialup port. Or you can route them to a T1. Or you can route them to the loopback port, which is what most people do. The RBL doesn't filter the BGP table, at all. > I do, however, filter blocks which should not be routed - e.g RFC > 1918 - and would like to include the non-assigned blocks. I just can't > figure out a way to automate such a process. Especially since the whois > servers limit the number of queries. (I'm not complaining, I understand > the reasons, I'm just stating a fact.) You can't automate it, easily. But by using the RBL, you can certainly get the real-time aspect of it handled well. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

Web Cache Question
by sonick＠mediaone.net 29 Jun '98

29 Jun '98

This is purely an effort to discover the cause of a recent problem that has surfaced inside our organization. About the time the whole web cacheing/digex issue broke here, the organization I work for began experiencing unstability in IIS4 web servers that provide real time market data via the internet to customers all over the world. These servers show an incredible increased rate in FIN_WAIT connections, compared against the amount they used to show on average (literally one week ago.) It is a problem because the inetinfo process simply stops responding. My question is this: is it possible there are web cacheing servers still in-line with major transit providers that we don't know about? If these servers exist: do they all operate on the premise of spoofing the source address as coming from the client, or would I actually see the cacheing servers source address? At this point, the only evident proxies in a server netstat are from AOL, but this is nothing new. The real increase in unexplained stale sockets are from random source addresses (spoofed?). Again, this mail is solely for the purpose of troubleshooting an exasperating, unexplained problem, not a blame the cache mail, so no return spam please. Any thoughts or recent similar experience sharing would be greatly appreciated. Jayson Anderson An Organization

2 1

on the issue of proxy-caching and new technologies
by alan＠mindvision.com 29 Jun '98

29 Jun '98

I've just read through the 20 or so email messages in the thread regarding the use of proxy-cache traffic on http traffic. I believe DIGEX should be congratulated on their forward exploration of technology. Their creative solutions to problems like this are the spirit that will sustain the Internet. DWDM and huge fiber builds will get us part of the way to handling internet growth, but we need to find ways to utilize upper-layer tweaks to do more with less. -alan

3 2

Re: Digex transparent proxying
by Paul Vixie 29 Jun '98

29 Jun '98

> >(performance for the FIRST fetch through a proxy is SLOWER - it HAS TO BE, > >since the proxy must first get the data before it can pass it on). > > It doesn't have to -- think cut-thru switching. I've no idea if > any/enough of the proxies do this. Yes, some do. And I wanted to give one thing Sean said more air time so folks won't just gloss over it: > 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. This is rather important, both because the stacks used in last-mile devices (such as the Microsoft Program Loader) are not very modern, and because HTTP persistent connections end up not being very helpful until they are aggregated across multiple last-mile devices. And in these senses (cut through with segment reblocking; reasonable/modern TCP handling; more use of persistent HTTP), someone with tcpdump actually would be able to tell that my particular transparent caching box was in use. I'll leave the challenge to Karl open, though, since I meant specifically "be able to tell from the client or server end" not "be able to tell using tcpdump on a LAN wire upstream of the caching box". -- 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)

2 1

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

29 Jun '98

| some of the content providers in the US would turn over in their graves if | they knew what people who pay heaps more $$$ for traffic are doing to | their web sites :). Let them turn. The easy fix for them is to duplicate their content elsewhere in the world, so they can control it themselves, and reduce the need for caching by operators like you. Sean.

1 0

Greener grass on the other side of the fence
by Sean Donelan 29 Jun '98

29 Jun '98

>As an aside, it always amazes me that the Internet even works (particularly >for an infrastructure that the unwashed masses seems to think will replace >the existing telephone network), but I guess the same could be said of any >chaotic (in the non-linear sense) system... I'm not sure the telephone network is really that robust. Think about the SS7 network and a world with 50,000 CLEC's. Like most things, you don't want to really know what's in the sausage. Some systems are designed with a high degree of control, so everything works correctly. But they often have the property of catastrophic failure when any part fails to work perfectly, such as the cascading failures of the western power grid last year. Central, hierarchial control is alluring. But there are still trade-offs. It used to take a week (or more) to add/change/update network routes in the prdb (and its predecessors). Perhaps acceptable when the central control was working, but it also took that long to fix things when the central database was screwed up. If you were really lucky, you might be able to convince someone to do an 'emergency' change in a day or two. We (myself included) often express amazament how the network manages to continue functioning. However, the system might not be as out-of-control as some people think. It is definitely chaotic. On the other hand, it has shown itself remarkably resiliant to the many evil things people and nature have done. I'll note I'm writing this note while watching white scan lines roll over my highly reliable TCI cable service, NOT! -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2