June 1998 - Test - lists.nanog.org

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

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 26 Jun '98

26 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 26 Jun '98

26 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