[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-vandevelde-v6ops-nap-01.txt - "maybe add a bit more on proxy servers ..."
On Fri, 18 Mar 2005 13:10:32 -0800
"Li, Qing" <firstname.lastname@example.org> wrote:
> > If the proxy breaks,
> > devices would not be able to access the resources they may
> > still have an IP layer path to. Proxys are worth avoiding for
> > the same reason NAT is.
> Actually for a transparent proxy if it breaks, and you still
> a valid path then the requests go directly to the origin
I'm not all that familiar with transparent proxy operation, other than
knowing they "catch" TCP port 80 connections as they "go by", and send
them to a proxy server instead. Does the router performing this
"catching" monitor the availability of the proxy server ? I'd probably
assume so. Still, if the proxy server fails, it takes with it any
current TCP connections.
I think the key thing to remember about the scenarios we are discussing
isn't whether subsequent, new TCP connections will work, it is whether
existing TCP connections will be destroyed due to a failure in the
network. Assuming alternative IP paths exist, in a stateless scenario,
existing TCP connections will survive, in a stateful scenario they
> > whether it changes surrepticiously or not. I first came
> > across this idea in Steve Bellovin's paper, "Distributed Firewalls",
> > http://www.cs.columbia.edu/~smb/papers/distfw.html
> > Secondly, deploying policy to the end hosts also provides the
> > best user granularity with the policy, as generally, it is
> > one end-user to one host. Identifying users at a per-host
> > level tends to be easier than network based identification
> > mechanisms. They also tend to be more fault tolerant, as a
> > failed policy (e.g., deny all access) on a user's host only
> > effects the single user, rather than a significantly larger
> > user population.
The above text is going to sound a bit contrary to my last email. In
the above text, when I used the term "network based identification
mechanisms", I was meaning using IP addresses to identify users on a
device remote from the node the user is currently using. eg a
> I haven't read the paper, but just reading the above,
> I wonder why would tie in one end-user to one host be a
> benefit ?
> A host can be used by multiple users, and each user needs to
> be authenticated possibly centrally to determine what network
> resources the user is allowed to access.
> The policy should be managed centrally and should follow the
> user and should be session based. When a host crashes it does
> not take down any policy and the user just go somewhere else
> and resume work.
The Internet's nature is peer to peer.