Paul,
Thanks for the discussion of some of the real problems with
transparent proxying/hijacking ("a pretty bad idea"). It is hard to
make such a product "transparent" -- other comments we have heard from
L4 switch vendors have indicated that a lot of babysitting is necessary
for example to add host:port pairs to a stop list for any host that
assumes it is talking directly to the client (for client authentication
or other purposes). Such manual configuration cause problems for
network administrators.
The point of my post could have been made more clearly: I don't
think labeling session hijacking with a perjorative "Evil" is necessary.
It is important to understand why it is being done (ISPs need to get
client browsers configured) and problems with the current solutions.
And I agree that we should look for clever ways to address the problem.
I like the idea of autoconfiguration, perhaps via a DHCP/BOOTP [vendor]
extension. (These users are likely already using DHCP for IP address
assignment, IP gateway auto-configuration, DNS server location, etc.)
Suggestion: BOOTP extension code=80, len=4, value=IP-addr of web cache.
The trouble with this is it requires ALL browsers in the world to be
modified to know about it. That's simply not going to happen soon.
Thanks also to Ingrid for noting (1) "Breaking connectivity at
the IP layer is Evil." and (2) "... to deal with September and students,
may accept L4 switches soon" :-)
> From: Paul A Vixie <paul@vix.com>
>...
> what is webrepl?
An IETF working group proto-charter is enclosed below. Regards,
-- jad --
John Dilley <jad@hpl.hp.com>
------- Forwarded Message
To: webrepl@cs.utk.edu
Subject: wrec round 2
Date: Fri, 25 Sep 1998 13:32:29 -0700
From: Scott Michel <scottm@cs.ucla.edu>
I appreciate all of the feedback I've gotten so far. Admittedly,
it wasn't a particularly well-articulated document. Here's the
points I was trying to pose as the goals of this proto-WG:
- - There are clients. There are origin servers. There may exist
structure between clients and origin servers. Clients shouldn't
be manually configured to use this intermediate structure,
otherwise, things like packet hijacking and request hijacking
become the norm.
- - Packet and request hijacking is A Really Evil Thing. So, one goal
is the design of protocol and mechanisms for getting clients to
discover this additional structure and use it. It can be as simple
as discovering an enterprise's egress proxy to discovering Keith's
"oracle".
- - There are a lot of caching systems out there, the dominant one
appears to be Squid (and Harvest). There will be others as well
(successful PhD research notwithstanding). What kind of metadata
could or should these caching systems exchange with each other?
Do we even want caching structures to interoperate with each other?
As a personal note, I'd really like to see the Adaptive Web Caching
thesis work I'm doing become a useful caching system. But AWC will
need to interop with Squid/Harvest at some point to extend the size
of the global cache. And there's no reason why Keith's idea of a
replication and mirror oracle can't be useful to a Squid root server.
- - Structure requires some kind of architecture and requirements doc to
describe the various entities and their interactions.
As Keith pointed out, "proxy" has some semantic context which is
too restrictive. This structure encompasses mirrors, caches, proxies,
tunnels, gateways, etc. RFC 2068 simply calls it 'servers' (1.3,
Terminology). We need terminology...
- - One thing I tried to stay away from is the copyright issue. As Ingrid
Melve pointed out to me in a private e-mail, there is a per-copy charge
in the fine country of Norway for xeroxing documents. However, we might
incorporate some language about this in a security scenarios document.
I don't think we want the scope of wrec (for lack of a better name) to
have too large a scope. If we can at least come up with a few approaches
and possible standards-track RFC for client<>"structure" autodiscovery
I think we'd be able to declare the WG a success on that point alone.
- -scooter
------- End of Forwarded Message
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST