Subject: Apologies/JANET caching issue
Ezri Carlebach (e.carlebach@acu.ac.uk)
Date: Fri, 26 Feb 1999 15:30:57 +0000
Message-Id: <36D6BE02.41749957@acu.ac.uk> Date: Fri, 26 Feb 1999 15:30:57 +0000 From: Ezri Carlebach <e.carlebach@acu.ac.uk> To: <arl-ejournal@arl.org> Subject: Apologies/JANET caching issue
These are comments from the ACU Webmaster regarding the JANET caching
issue. Here they are:
Ezri Carlebach
<e.carlebach@acu.ac.uk>
> On Thu, 18 Feb 1999, Daniel Feenberg <feenberg@nber.org> wrote
> >
> > The problem is that traffic from English universities now goes
> > through a cache engine in the domain wwwcache.ja.net. Since this
> > computer covers all English universities, I can't put it in our
> > authorization database.
> >
> <snip>
> >
> > One proposed solution, which works for some sites, is to browse
> > a special web server we have set up on port 81 of our web server.
>
> This may work at the moment, but there are potentially large problems
> with it. Within the limited context of Janet, sites tend to have
> unfettered access, but many ISP's in the UK these days insist on their
> users using their cache. As these ISPs' intent is to reduce their
> requirement for transatlantic bandwidth, they will often block traffic
> on ports not serviced by their caches. As I mentioned,this isn't
> happening with Janet at the moment, but it is a possibility for the
> future.
>
>
> > I understand that some sites passs port 81 to the off-campus
> > cache,defeating this strategy. If any significant usage were to
> > develop on this port, we would modify our server to automatically
> > recognize requests from Janet, and automatically specify port 81
> > in HTML returned to those sites.
>
> The procedure you've outlined would effectively kill Janet's caching
> strategy for your site. If enough sites do this, Janet will "retaliate"
> by pointing port 81 at the off-campus cache, and you're right back where
> you started. Then you pick up on port 82...
>
>
> > If you want to make this subscription work, I suggest going to
> > the library staff person in charge of online publications.
>
> This isn't the first time I've seen this discussion hashed out. Last
> time I saw it, an engineer at Cisco got involved (don't ask me how).
> His take on the matter was that in the current internet environment,
> where more and more aggressive, user transparent, server side caching is
> being carried out, authentication via subnet is fundamentally flawed.
>
>
> > The alternative that I have suggested in the past is for Janet to
> > enable the 'X-Forwarded-for:' header for requests.
> >
> <snip>
> >
> > However, Janet has made a policy decision not to provide that
> > header, to enhance privacy.
>
> This might work very well, but I'm forced to admit that the privacy
> argument is one I find compelling these days. In the context of Janet,
> you may be able to make the policy limp along with an acceptably low
> problem level. IP authentication is being used by a number of sites,
> based (I believe) on the fact that it is probably 95% effective right
> now, and it's not too hard to set up compared to the alternatives.
> However,should you ever find yourself in the position of wishing to
> offer services to the commercial sector, who will have their net access
> via a commercial ISP, I think you may well find the situation very
> different. In my experience, some commercial ISP's proxy everything,
> and the non-proxied ports may be simply blocked. Personally,I find this
> kind of thing odious, and choose ISPs that don't indulge in this sort of
> practice, but if low cost high bandwidth connections become a reality
> here (xDSL, baseband, et al.) then I suspect that many more ISP's will
> adopt such policies,as their users will suddenly have access to 2MB (or
> thereabouts) of bandwidth, and the ISP, while maybe happy to provide
> them with this locally, is unlikely to be willing to allow their
> transatlantic lines to be eaten up like this.
>
> Now I may be being overly pessimistic here, and these issues may turn
> out to not be a serious concern to you, but I'd be interested in what
> you decide to do. I have yet to find an authentication method that gets
> around all of these problems, without placing an unacceptable number of
> requirements on the users, or the site administrators, or both. All the
> methods I've seen so far seem to revolve around people trying to bend
> http in directions it was never intended to go, and the results are
> never satisfactory. One option perhaps worthy of consideration would be
> to use https, and require the client to authenticate itself. For a
> site-wide license, you'd still have problems distributing appropriate
> keys however...
>
> I personally don't believe that IP subnet authentication is a good way
> to achieve what you're trying to do, but I have to admit that I can't
> see a decent alternative right now. It seems to me that you can live
> with what you have, warts and all, or you can invest lots of time and
> effort into looking for alternatives that may well prove to have more
> warts than the current setup. Or you can hang on in the hope that some
> technology around the corner will solve the problem. This sorts of
> thing is creating trouble for anyone wishing to sell electronic products
> across the net, so I would imagine pressure will force a solution out
> sooner or later. Alternatively, you could develop a wonderful
> innovative fix to this, and become a millionaire overnight :-)
>
> My 2p worth,
>
>
> Mike Brodbelt, ACU Webmaster
via
Ezri Carlebach
Editor, Print and Electronic Media
The Association of Commonwealth Universities
John Foster House
36 Gordon Square
London WC1H 0PF
UK
Tel: +44(0)171 387 8572
Fax: +44(0)171 387 2655
WWW: http://www.acu.ac.uk/
<e.carlebach@acu.ac.uk>
This archive was generated by hypermail 2a16 : Wed Dec 22 1999 - 09:15:06 EST