[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 ..."
Hi Qing,
On Fri, 18 Mar 2005 11:18:35 -0800
"Li, Qing" <qing.li@bluecoat.com> wrote:
>
> >
> > RFC 2775 and RFC 3234 addressed these issues, I believe.
> > While I wouldn't be as negative as that about proxies, I do
> > think that it would divert from the main argument in the NAP
> > draft if we expanded that topic.
> >
>
> Since a good portion of the document discusses untraceable addresses,
> therefore I also believe the document should have some discussion
> on proxies.
>
> In the SOHO/home environment, privacy and secure end-to-end
> communication is of main concern, which are not necessarily desirable
> or applicable in the enterprise environment. One has very little
> control and right to claim privacy in the enterprise environment.
> Think of individual users on the DoD networks.
>
> In the enterprise environment proxies are deployed to enforce enterprise
>
> network access policies. The privacy extension of generating temporary
> addresses and making addresses difficult to trace would make the
> enforcement task a difficult one. For example, a fixed policy rule
> such as:
>
> address time-of-day week-day bandwidth-alloc
> --------------------------------------------------------------
> IPv6-addr-X 9:00AM - 3:00PM M,W,TH,F X-kbps
>
> would be difficult to enforce if IPv6-addr-X either constantly
> remaps to a different node, or if the node constantly replaces
> IPv6-addr-X with something else.
>
> In other words, some of the goals of NAP (probably more accurately
> the goals of address privacy extension) are contrary to the
> enterprise network management goals, which are identification,
> control, and enforcement.
The key term here is identification. When you identify using a network
layer address, you aren't really identifying a person, you are
identifying a node, and then basing all your security and policy on the
assumption that the person the policy is applying to will always use
that node. While humans continue to be portable and mobile, that is a
relatively weak assumption. I've seen that assumption broken often
enough when, for example, people in an enterprise network who don't have
Internet access or special application access want it temporarily - they
just move to another node that does. Obviously those people are breaking
the access policy, the question is, are they bothering to try because
the policy barriers are quite low and therefore their chances of success
are high ? Because it isn't too hard, they may not consider they are
breaking important rules.
Ideally, policy should be able to be applied to the user no matter which
node they happen to be using at the time. A network location independant
user identification method would be better, such as username / password.
Once the user has been identified, the specific policy for the user
could then be deployed to the node they're currently about to use.
So I guess my question is how does
> NAP fit in this type of enterprise environments ?
>
> A secure proxy can be means to NAP. Many of the proxy functions
> require connection termination and if the policy allows, another
> connection is originated by the proxy on behalf of the client,
> effectively hiding the identity of the client.
>
> The argument that a proxy breaks the end-to-end model is not
> entirely true. Once the initial authentication and authorization
> step is complete, later communication would require a simple
> connection-splicing in the proxy, much like what a bridge/route does.
> Of course in the case of HTTPS termination the proxy does more work
> for decrypting/re-encrypting traffic. Secure proxy appliance
> usually require NIAP and/or FIPS certification.
>
I've understood that the major benefit of the end-to-end argument, in a
networking context, is that you don't build single points of failure
inside the network, by chosing to maintain state in an intermediary
device, in scenarios where a single point of failure didn't previously
exist. Following on from that, if you do maintain state in the network,
to then eliminate those single points of failure, significant complexity
has to be added.
For example, imagine a geographically large network, with Internet
connections at two cities, and an private WAN between them. It can cope
with one of the Internet connections failing - the traffic will be
rerouted from the local Internet connection, across the private WAN, and
out the remote Internet connection. Individual TCP connections will
survive this sort of transient failure, as they don't rely on the
specific devices that are helping them communicate.
However, if you were maintaining proxy servers at both sites, for TCP
connections to survive a proxy failure, you now have to keep the two
proxy server's states synchronised. This is complex, and will be heavy
on traffic (every TCP segment each proxy sees will generate another
synchronisation packet between the proxies, for example), which may
require much higher bandwidth links between these proxy servers than the
normal traffic requirements of the private WAN.
The stateless, "router only" model is a lot simpler.
> The other argument about the proxy breaks the security model
> whereby the origin server identifies the client based on its
> IP address is flawed. Identification on IP cannot identify
> the individual users on the node, so origin server cannot personalize
> the content by IP alone. You don't need a proxy to get into trouble.
> If the node acquires globally routable address from a
> DHCP server we run into the same issue.
>
That is another good example of where network location and node identity
(ie. IP address), are not identifying a person but a node.
Regards,
Mark.
--
The Internet's nature is peer to peer.