- NANOG - lists.nanog.org

Re: Digex transparent proxying
by Chris Fournier 27 Jun '98

27 Jun '98

> > Not to mention those to derive advertising revenue from "views", and have no > > way to measure them in a cached environment. If I was doing that, I would > > also deny service to proxy servers and display a nice message telling the > > user to remove the proxy or bitch about its forced use. > > Karl that is silly - in the a lot less time and effort that you would put > in setting up your redirect - you could have just used a correct Expires > header and has your content (or at least just the suff that you want to > remain dynamic) avoid the cache. It serves you as the designer as much as > it serves the enduser (speedier loads). If your page comes up quickly > chances are the person will venture around a bit londer and click more > links in the 20 minutes that they have before their date picks them up > etc... It's common sense. I Believe what Karl is trying to point out, is that alot of sites pay for unique views. If you look at software like NetTracker or most other web site tracking software define a unique view as a view from a unique host. By forcing the use of a BACKBONE Proxy you are going beyond the normal provider level and grouping a large number of providers and regions together into a few hostnames. What they are doing is turning 10,000+ unique hosts into a few unique hosts in the name of saving money. -Chris alpha(a)meganet.net

1 0

Re: transparent caching....
by Paul Vixie 27 Jun '98

27 Jun '98

mo(a)UU.NET (Mike O'Dell) writes: > I've been talking myself blue in the face for some time now > trying to convince the never-ending parade of would-be > cache builders that busting a gut to be "completely > transparent" was simply not worth the effort because i was > convinced it would turn out to be a bug and not a feature, > especially when people had to troubleshoot problems. I have come to agree with this, in the large. But it was and remains an interesting technical problem, and I feel strongly and proudly that our box was the only one that got it *right*. -- 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 Paul Vixie 27 Jun '98

27 Jun '98

> 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. yes, but they don't, and they won't, not ever. expecting other people to do the right thing is just not a hallmark of good operational practice, nor is it a NANOG tradition. > > 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. "go ahead, make my day." as the principal architect of a caching product which served up yesterday's newspaper when today's newspaper was wanted, for pretty much all of 1997, to about two dozen hardy "early adopters" (you can tell who they are by the flaming arrows sticking out of their backs), i'm now perfectly willing to challenge you to find any content, no matter how broken or mangled or missing its headers are, that a Web Gateway Interceptor can't serve correctly. and that's without any central registry of "bad content" such as that described by in the post here from inktomi earlier in the day. i'm not saying this out of a desire to use NANOG for product advertising; my last caching product pretty much served its purpose by showing that this kind of caching doesn't win back enough bandwidth if correctness is the goal, and the product has no distribution channel at all. i can't make money by arguing about transparent caching on NANOG -- trust me. so really i'm just flaming. correctness *can* be maintained. content creators will *not* do the right thing. anybody who says otherwise is welcome to tell me a URL they think my WGI can't serve and also show me mail from a content creator saying "thanks for telling me that i was doing the wrong thing, i'll fix my Expires: headers immediately!" -- 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

"RelayFinder" Anyone else seen this? (erols, fnord, oneill may be interested)
by Ryan K. Brooks 27 Jun '98

27 Jun '98

Had a new box on the net for all of two hours, and this pops up on in my maillog: Jun 22 22:18:41 x sendmail[509]: WAA00509: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "250 <relayfinder(a)fnord.net>... Sender ok": Broken pipe Jun 22 22:18:41 x sendmail[509]: WAA00509: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "250 <relayfinder(a)fnord.net>... Recipient ok": Broken pipe Jun 22 22:18:41 x sendmail[509]: WAA00509: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "354 Enter mail, end with "." on a line by itself": Broken pipe Jun 22 22:18:41 x sendmail[509]: WAA00509: from=<relayfinder(a)fnord.net>, size=81, class=0, pri=30081, nrcpts=1, msgid=<199806230318.WAA00509@<MY FQDN WAS HERE>>, proto=SMTP, relay=autumn.news.erols.com [207.172.3.57] Jun 22 22:18:41 x sendmail[509]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "250 WAA00509 Message accepted for delivery": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "503 Need MAIL before RCPT": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "503 Need MAIL command": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "X-Scan-Time: 898571908"": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "X-CIDR-Block: <MY /16 WAS HERE>"": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "X-Relay-Address: <MY IP ADDR WAS HERE>"": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "."": Broken pipe Jun 22 22:19:57 x sendmail[511]: WAA00509: to=<relayfinder(a)fnord.net>, delay=00:01:16, xdelay=00:01:16, mailer=esmtp, relay=luser.oneill.net. [207.96.89.34], stat=Deferred: Operation timed out with luser.oneill.net. It looks to me like someone on the host at erols tried to relay through me, and then mail the potential results to themselves at fnord.net (relayed via oneill.net) Is someone attempting to perform a community service here and scan the entire Internet for relays, or are they collecting relays for evil purposes? I can see it now; buy "10 million relay sites on a cdrom for $9.99". Ryan Brooks ryan(a)inc.net

7 6

Re: backbone transparent proxy / connection hijacking
by owen＠DeLong.SJ.CA.US 27 Jun '98

27 Jun '98

> 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. > But, as you point out, this basically requires that each server using this authentication model be identified, then corrected on the cache server on a case-by-case basis. While such servers are, at this point, a rare occurence, it does happen, and developers should be free to use this technology if it meets their needs without fear of having their clients suddenly disconnected from them by their client's ISP. > 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. > Although this proxy is broken, and the owners should upgrade, there is still the issue of choice. > 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. > Weak or not, it is in use. As such, it is not appropriate for an ISP to inflict this technology on all of their customers without consent from the customers. > 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. > While this is a good positive customer service step, it is not by any means a complete resolution to the problem. It still requires a (potentially) good deal of overhead to keep the list of anomolies up to date on the server. Further, the cache server inherently degrades performance to these sites. > 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. > This is a much better and likely more thorough way to gather a list of anomolies. However, given that, I'm surprised you didn't catch the CyberCash issue prior to it becoming one. > 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. > Maybe, but it's use should be voluntary on the part of both sides. Otherwise, the cache implementors (not Inktomi, but the ISPs who implement transparent caching for all their customers) are providing a service different from that expected by the bulk of their customers when they sign up. > Paul Gauthier > Owen DeLong Opinions expressed are mine and mine alone, and do not reflect the views of my employer, were not cleared by my employer and were submitted to the net from a machine not owned or operated by my employer.

2 1

spam as an operational issue
by Matt Sommer 26 Jun '98

26 Jun '98

A dial-up customer complained about bounced messages from Sprynet. I think their explanation may be of interest to Mr. Dean "Spam Costs Next to Nothing" Anderson and a few others. Note that sprynet runs four mail servers round-robin. -----Original Message----- From: Postmaster of Sprynet/Interserv <postman(a)interserv.net> To: sysadmin <sysadmin.h8s.spam(a)webkorner.com> Cc: postmaster(a)sprynet.com <postmaster(a)sprynet.com> Date: Thursday, June 25, 1998 8:44 PM Subject: Re: smtp connection difficulties >we had a massive spam attack today. sorry for any inconvience > >On Thu, 25 Jun 1998, sysadmin wrote: > >> Date: Thu, 25 Jun 1998 17:14:54 -0400 >> From: sysadmin <sysadmin.h8s.spam(a)webkorner.com> >> To: postmaster(a)sprynet.com >> Subject: smtp connection difficulties >> >> Hi, >> >> We are having great difficulty connecting to port 25 of your mail servers. >> We are usually getting 'connection refused' messages. Our mail server is >> mail.webkorner.com (207.53.76.15) and has all proper dns entries, including >> reverse dns. Are you having any system difficulties? >> >> Thanks, >> >> Matt Sommer >> Sysadmin >> >> >> >

1 0

New Modify template
by Kim Hubbard 26 Jun '98

26 Jun '98

Hello, To enable you to modify ARIN WHOIS records, ARIN now offers a multi-purpose Modification template that is web-based and user-friendly. Using this modification template, you may now update Network, ASN, or POC information, delete in-addrs (host records), and return IP numbers and ASNs. Please note, only the records of IP numbers that were received directly from ARIN or its predecessors may be updated using this template. For those of you receiving addresses from your upstream ISPs, please contact your ISP to update your network records. To avoid delays or errors in processing please take the time to review the detailed instructions prior to submitting changes. The new modification template is located at www.arin.net. As always, we welcome your suggestions. Cheers, Kim Hubbard ARIN

1 0

The Cidr Report
by Tony Bates 26 Jun '98

26 Jun '98

This is an auto-generated mail on Fri Jun 26 12:00:00 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 26Jun98 0) General Status Table History ------------- Date Prefixes 190698 51379 200698 51329 210698 51500 220698 51541 230698 51362 240698 51537 250698 51460 260698 51523 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 213.102.1.0 from AS3259 *** Bogus 214.0.0.0/8 from AS568 AS Summary ---------- Number of ASes in routing system: 3669 Number of ASes announcing only one prefix: 1763 (935 cidr, 828 classful) Largest number of cidr routes: 350 announced by AS3561 Largest number of classful routes: 1145 announced by AS701 1) Gains by aggregating at the origin AS level --- 26Jun98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 452 247 205 45.4% IMCI AS2493 488 283 205 42.0% iSTAR Internet, Inc. AS3602 511 313 198 38.7% Sprint Canada Inc. AS701 1145 950 195 17.0% Alternet AS271 336 145 191 56.8% BCnet Backbone AS3749 218 70 148 67.9% TECNET AS174 725 587 138 19.0% Performance Systems International AS4755 106 32 74 69.8% Videsh Sanchar Nigam Ltd. India AS3218 78 7 71 91.0% AS-RSSI AS7046 218 148 70 32.1% UUNET-CUSTOMER AS3221 112 42 70 62.5% EENet Autonomous System AS6227 96 28 68 70.8% !nteract AS10928 107 42 65 60.7% UNKNOWN AS5668 116 54 62 53.4% Century Telephone Inc. AS3804 208 146 62 29.8% Bell Solutions AS4740 382 328 54 14.1% ASN-OZEMAIL (Ozemail Pty Ltd) AS3403 180 127 53 29.4% TIAC AS2685 133 83 50 37.6% IBM Global Network - US AS549 194 145 49 25.3% ONet Backbone AS8517 120 72 48 40.0% ULAKNET-ASN AS72 85 37 48 56.5% Schlumberger Information Network AS6335 68 20 48 70.6% NTRNET AS4539 73 25 48 65.8% NETROPOLIS AS4200 145 97 48 33.1% AGIS (Apex Global Information Ser AS1239 543 496 47 8.7% SprintLink Backbone AS719 449 405 44 9.8% LANLINK autonomous system AS852 158 116 42 26.6% AGT Advance Communication AS762 118 80 38 32.2% WELLFLEET-AS AS6181 65 28 37 56.9% FUSE-NET AS4763 109 72 37 33.9% Telstra New Zealand For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

FYI:The ISP-Caching Email Discussion List
by Kent W. England 26 Jun '98

26 Jun '98

There is a list for ISPs to discuss proxy-caching. It isn't incredibly active, but it is a good place to ask questions and to receive a lot of vendor hype. --Kent >-- > >Welcome To The ISP-Caching Email Discussion List! > >The ISP-CACHING list is designed to focus its discussion 100% on >Caching systems, whether they be Squid type software, proxy server >solutions, the new satellite caching systems, or any new caching >system that has yet to be released. ISP's who want to save money >by eliminate unnecessary bandwidth waste will be benefited by >discussion on the ISP-Caching list. > >For your first post, send an introduction of yourself, your business, >and what your current CACHING hardware/software configuration is, and >any question or comment you might have. > > >How Do I Post To This List? >--------------------------- >Send An Email TO: isp-caching(a)isp-caching.com > > >How To Get Off This List: >------------------------- >Send An Email TO: remove-isp-caching(a)isp-caching.com > > >How To Join This List: >---------------------- >Send An Email TO: join-isp-caching(a)isp-caching.com > > >Please direct any problems TO: isp-caching-owner(a)isp-caching.com > > > >

1 0

GRE advisory
by Alex Bligh 26 Jun '98

26 Jun '98

For those of you who mailed me privately to ask for the URL of the GRE (and other tunnel) advisory detailing how to detect and prevent abuse of exchange points etc. to steal third party transit, sorry, I lost most of your email addresses, but it's at: http://www.linx.net/tunnel-advisory.txt (for those who saw it before, no it hasn't changed). -- Alex Bligh GX Networks (formerly Xara Networks)

1 0